It's more than an implementation detail. With an intermediate step of source code compiling & linking, there is a mechanical process checking for well-formedness that would otherwise be skipped. This is especially important if you're editing a large codebase, which even your agent's private-only repo would benefit from.
There are also times when you want the final product to be able to target different architectures and platforms. Generating into a higher level language allows for re-targeting the code by only changing a few compiler & linker flags or runtime/environment config. I would much rather that than hoping the LLM is feature- (and bug-)compatible between generation runs.
The same assumptions are true about giving any human that shareable link. They could pass it on to anyone, screenshot it, paste it into their own session. This has been true since before "share with link" permissions on Docs and elsewhere.
If you click "provide a shareable link" you should decide (and behave) as though that made it public.
I'm not saying it's good privacy posture on the side of the companies, but how else do you think that would work if there isn't any authentication step for the person viewing it? Even with authentication, "three may keep a secret, if two of them are dead."
Not quite.. that boolean is about whether the voltage exceeds some threshold. It's not about how close the voltage is to the circuit's maximum possible threshold, or how much it exceeds the threshold.
Both the voltage and the threshold are probabilistic. Within a tight envelope sure. This is true even of the physical fields that comprise the transistor itself never mind the signal it’s designed to discretize. A more extreme example is a transistor hit with a stray gamma ray. When you dig deep enough there isn’t technically a Boolean anywhere, that’s a platonic construct that makes discussion of engineering convenient.
You specifically said "digital" in GGP comment. I took that to mean that you were choosing the abstraction above which those details matter. Yes, at the physical level all circuitry is effectively continuous and stochastic. Analog circuitry is the manipulation of these to give a more continuous state, digital circuitry uses voltage ranges and a forbidden middle to enforce a kind of noise immunity. When you dig deep enough that the noise is a point of concern, you are no longer looking at a digital Boolean.
An AI assistant can give different answers for the same inputs. An application written by an AI assistant, if it doesn't just call an LLM at runtime, will mostly likely produce the same answer for the same inputs. That is, unless there's something intrinsic to its business logic that makes it nondeterministic.
Sometimes you really want the latter even if the former is less effort.
And when applicable, the program would be much more efficient than the LLM.
So it would really be beneficial for the LLMs to be able to have their own environments to write and run code, but also to store those programs for later use automatically.
A *human* assistant can give different answers for the same inputs. At some point, we'll need to stop treating computers as instruction executors and start treating them as autonomous agents. Non-determinism isn't a bug to be fixed, it's just the reality of working with this new kind of machines, and operators of those machines need to embrace that fact, like they did for human assistants.
And we started adding rules for the humans to follow, until we have complex bureaucracy. We invented tons of formal notations systems and error detecting and correction mechanisms. We invented deterministic machines. All because we are deeply unsatisfied with the non-determinism! Because it means you can never trust some process, optimize it away and stop thinking about it. You always need to check, and there is always something missing.
A lot of our manufacturing ability improvement during the last 200 years, as well as our engineering ability improvement during the last 500 years, is not just the raw power we unlocked, but that we made it deterministic, reliable and reproducible and hence automatable and automatic.
There's a reason bureaucracy has negative connotations. Also, notice how we still ended up with a system where everybody in the bureaucracy has a lot of leeway in what decisions they make.
Can you build a new hospital? Up to the local government to decide. How much is your property tax? Only a tax assessor can tell you. Which trees get trimmed and which are left intact? Decided on case by case basis with no strict rules. Which convenience stores are getting audited for tax and food safety compliance this week? There's a middle rank officer who makes that decision every week, my mum used to be one. How high is the bail set in criminal proceedings? Judges are famously very inconsistent on that and it's a good thing. In countries without constitutional gun rights, it's common that the final step in the process of obtaining gun permit is some government employee having a good gut feeling about you, and if they get bad feeling you get denied. And so on and so forth everywhere you look.
Manufacturing is a different beast entirely. I'm not saying we should put Siri and Cortana in charge of bolting down Boeing fuselage. But for most office and bureaucratic tasks, demanding perfect determinism is not only unnecessary but actively harmful.
That's not caused by bureaucracy itself, but by the rules given. You can have the same with non-rule-based systems, except then you don't even know which rule is the fault, and neither fix it nor complain. That's absolutism and corruption. Bureaucracy is a huge improvement.
So would you want a genius figuring out how to do everything you ask it to from scratch, or do you want to train someone how you want something done, so they do it the same way every time and you don’t have to explain yourself over and over?
Nondeterminism is actually a bug in many cases, and training, process and procedure, is how we mitigate it in humans.
You know what they call doing a task the same way every time? Micromanagement. Red tape. Waterfall design. In general, a bad thing. Kills creativity, slows everything down, minor setbacks become huge problems because there's no flexibility.
Defining every single step of every single task and making them perfectly repeatable works in an assembly line. But as an office assistant - and doubly so as a personal assistant - it creates inefficiency, makes dealing with edge cases very painful, and greatly increases maintenance burden of keeping all procedures up to date. Instead, giving people some leeway in how they approach their tasks and deliberately underspecifying processes to let them exercise their judgement is shown to work much better. Surely you had it covered in your training materials?
But sometimes you do just want the same answer each time. Not this human woo crap, where the answer depends on god knows what, but a deterministic function of some kind, reliably producing a given output for a given input according to a fixed set of rules.
Yes, but sometimes (quite often actually) you really don't care. The entire subfield of audiovisual compression is built around the principle that you don't care. The data is actively being lost and the image distorted, and you're fine with it. Wanting deterministic results out of MP3 is like wanting AC units to be loud. Sure, they are loud, just like MP3 is deterministic, but why exactly is being loud one of your requirements when choosing an AC unit? Isn't it enough to produce cool air, or in case of MP3 - sound good enough?
It would be like telling the computer to compress a music file containing Bach's Toccata and Fugue in D Minor, and getting back a file that contains Rick Astley's Never Gonna Give You Up. Maybe you don't care, but I do.
You are talking about AI outright failing to get anything remotely close to the correct result. That's a completely different argument and has nothing to do with non-determinism. Things can be deterministically wrong too.
Accuracy, precision and determinism are completely different things. Lossless compression reduces precision, and by that also accuracy, but it doesn't become undeterministic.
You've got terms confused. LossLESS compression does NOT reduce precision or accuracy. Unlike lossY compression, which does.
That said, my point is that determinism is incidental to how current generation of compression algorithms work, not an explicitly desired quality. And even that isn't strictly true, because e.g. x264 in certain multithreaded configurations already produces non-deterministic results that look as good as single-threaded encoding. For this use case - and thousands of others - losing determinism when switching to AI-based solutions really isn't a big deal.
I want an agent studio and execution sandbox where my LLM driven assistant builds and maintains my apps with a receipt or transcript like history of what it did to create each app. Determinism built per use case with non deterministic assistance orchestrating the build and management layer. Extra credit if I can trivially share and collaborate with others per “deterministic silo” via a shared link. Something like Claude Code + AWS Lambda|(Docker|Podman) + Tangled.org with LLM code generation for my phone and workstation.
The LLMs empower for building, the determinism improves output-expectation alignment. It’s fundamentally an on device software factory, hypervisor, and storage system.
Cattle can do complex tasks too. Including managing other cattle.
Think of all those bad sci-fi movies where aliens take over Earth, enslave all humans and treat them like cattle. Very competent cattle that's put in charge of local governments, scientific research etc. but very much still cattle where individuals are entirely interchangeable and killing them is just everyday work. This is me and AI assistants. (I'm the aliens.)
If the code works good enough, it works good enough. If good enough is insufficient for success criteria, you’ll have to trade app evolution velocity and flexibility for more determinism via more human effort (“artisanal hand crafted”), evaluated on a per use case basis. “Does this software have to be good? How good? Have I hit diminishing returns yet?”
Pros and cons to code being cheap to generate now, it’s always about tradeoffs. I don’t want to build cars, I want to drive cars.
Only in the sense that your build-a-car will be "good enough" as long as you never find out why your palms are always itchy, and you never press the brake so hard it stops working, and nobody determines which of the cars started the fireball during the accident.
People suck at "good enough". All major engineering disasters were something "good enough" for somebody. People burn down their houses with "good enough" electrical work.
They are different -- higher level languages like C++ and Python surface the abstractions, making them more apparent to the human reading the code. LLMs typically hide the abstractions. You can still read the source code, sure, but even the latest models will produce a lot of repetition of utility functions and produce data structures of various shapes without commonality or reuse. This is moving in the opposite direction that machine code -> assembly -> C -> ... were heading.
Prioritizing something other than 7% week over week growth. This doesn't appeal as much to venture capitalists so we may have to try it with some bootstrapped products first.
Having seen the abuse vectors that get thrown at this and similar products, I suspect it is less about whether they care and more about finding a suitable threshold for some arbitrary features, or moments of demand exceeding the available moderators. The repetitive 6 minutes make me suspect there are reports timing out in the moderator queue and the automod doesn't like images or something.
Or, perhaps a part of the process that is two or three teams away, like photo attachments being deemed too large (getting passed from Maps UI through internal task queues to some abuse analysis, or even as early as the frontends that take the request). Plausible, especially as phone photos have steadily increased in size while some thresholds remain ossified.
I'm outside that world now so I can't investigate or effect change.. there used to be people there who care about these things. I suspect there still are.
Even more likely is that other priorities exceed the capacity of the headcount on the relevant teams. I don't know if that counts as the company not caring. It's hard to attribute intent on corporate-scale embodiments. Perhaps that's the root of the problem, I wonder if any collective that reaches hundreds of thousands of members can ever exhibit that. Maps is a huge product that a small competitor could hardly compete with but I'd love to be proved wrong (either on the smallness or considerateness aspects).
This is the key to the problem that I think people are missing, possibly because they kind of want to miss it. Google and the other companies hiding behind LLMs and primarily doing it because they can't operate at the scale they do, with the dedicated ecosystems to gaming them that they develop, without this hiding. They can't afford humans to review in a minute or two what scammers can generate in fractions of a second, not even at their scale.
Now, I'm enough of a fan of decentralization and the destruction of these massive sites with way too much control to say that I'm perfectly comfortable saying that they should be mandated to handle these things more sensibly and with more humans. That such a plan would have the side effect of breaking them up into vastly, vastly smaller pieces, causing an technological Cambrian explosion of various sites and diversity resulting in the parasites no longer being able to focus all their firepower on a very small set of targets, is for me a bonus, if not the main goal. However, I, and anyone who agrees with me on this, is rather clearly in the minority.
In the meantime, if we're going to have things the size of Google or Facebook, there simply is no solution where we all get human review whenever we ask for it, because instantly every spammer and abuser will ask for the human review. There just isn't a solution. It looks like there is an obvious solution when you consider "how will Google review this one application" but that's not the landscape Google faces. They have to solve the problem of how to deal with the entire landscape of requests they face at once.
> This is the key to the problem that I think people are missing, possibly because they kind of want to miss it. Google and the other companies hiding behind LLMs and primarily doing it because they can't operate at the scale they do, with the dedicated ecosystems to gaming them that they develop, without this hiding. They can't afford humans to review in a minute or two what scammers can generate in fractions of a second, not even at their scale.
"Alphabet, Google's parent company, reported $112.1 billion in profit for the three months ending in June."
Ah yes, they definitely can't afford it.
I genuinely cannot grasp how someone who is capable of 1. finding hackernews 2. creating an account 3. writing a coherent English comment, can come to such an absurdly wrong understanding.
Scammers generating things in fractions of a second is an incredibly well understood problem that affects every single surface of the earth that has a "submit" button. Even completely anonymous services have largely managed to solve this. Google Maps requires a verified account, meaning it's entirely solvable. It's a non-issue.
Give me $112.1 billion every 3 months and I'll solve it for you, no worries.
This gets rid of the scams but makes all surviving reviews unreliable since they'd all be pay-to-play. It'd be better to just remove reviews altogether at that point.
Which doesn't seem like such a bad idea now that I've said it out loud.
Kind of, but not really.. though there are simple models with electrons as a point charge, a more accurate model involves the electron field describing the probability of an electron existing at any region in space (not to be confused with the electromagnetic field, the medium in which photons propagate).
Sure the position of an electron is not definite, but neither is that of a buckyball, but a buckyball has a shape we can describe, an internal structure we regard as extended over space, in a way that is separate from the indeterminacy of its center of mass position. This is unlike an electron, for which, if we set aside the uncertainty as to its center of mass, my understanding is that the only internal degrees of freedom it has left (in the Standard Model) are its spin and whether it is left or right handed, with no other structure to it.
It is in this sense that, AIUI, electrons are modeled as point particles.
Of course, that doesn’t mean that if we zoom in enough, probing at higher and higher energy scales, that it can’t turn out to have some non-zero fundamental size outside of just uncertainty in its center of mass position. I think string theory would say that at the string scale it would be a string.
But, AIUI, no experiment has shown it to have the kind of extent that would make it be called not a point particle (an extent in a sense beyond just uncertainty in COM position)
I think they're referring to the Enterprise sales where people have felt pressured to sign six- or seven- figure contracts after usage goes above a certain point. However, all the articles I've read on it are from companies using Cloudflare to do suspicious things with rotating domains through IP addresses, or doing things to try and get around service costs. It also seems like they give you months of warning and will try to convince you to sign up for Enterprise, they don't just shut things off. But their sales team seems to portray themselves as legal, support, or compliance teams sometimes so not exactly forthcoming in their approach either.
I'm a happy user of Cloudflare, but if you're using it for domain registration and hosting infrastructure, you need to see it as a single point of failure. Any account issues and you won't be able to point your domain to an alternate host while you work things out. Any service outage in CF systems will similarly lock you out of routing around the failure. It's better to have DNS off of cloudflare if they're handling your hosting services also. Or host elsewhere and only handle domains on cloudflare. Their domain pricing doesn't add any costs over the base registrar cost, so the latter is a reasonable option.
There are also times when you want the final product to be able to target different architectures and platforms. Generating into a higher level language allows for re-targeting the code by only changing a few compiler & linker flags or runtime/environment config. I would much rather that than hoping the LLM is feature- (and bug-)compatible between generation runs.
reply