"An ever-growing drive towards exploiting gambling instincts is being employed by AI coding agents and the companies developing them. The addictive nature of low-effort to high-output environment of LLM interfaces is being actively monetized, and incentives are once again stacked against you."
I decided to write about my experiences and observations about one of the less-discussed aspects of vibe coding: Its direct relationship to gambling, and how it's being marketed to inflate the AI hype cycle to the MOON!
I tried to be a little bit inflammatory, but please consider it seriously. Our relationship with AI agents is going to be an increasingly important one as they grow smarter. It's up to us to keep our instincts in check, and stay cool.
P.S. I would like to get in touch with people who think about this subject, are addicted to vibe coding and want to quit, and would like to provide more information/resources to substantiate this discussion, and expose the parties exploiting these addiction systems in the context of vibe coding.
You need to understand something about VC, tech, and finance people in general. They don't care about anything but making money. How do you make money? Sell shovels. Or better yet, monetize them. Rent and lease them out. Make shovels just well enough it breaks infrequently enough that people keep coming back to get another one.
That's vibe coding, and the last couple decades of "cloud mania". Computing was metered and rented. What they didn't have was the capability to bottle their developers up and sell that. Now, LLM's and the massive compute farms required to support them have given them that new shovel to sell. Which they will. Without regard for what it'll do to the environment that made it possible.
Leaks are more common on the pressurized side. Which is the clean water coming in. If you have hairy fatbergs in your supply you’ve got bigger problems.
The article describes them being “dropped in at hydrants.” So I think they’re punting on the “hairier” problem of the sewer side.
Edit: okay, I kept reading and they do mention pressurized waste lines. That does seem harder, especially since you’re going to get root intrusion on old public lines.
Unpressurized sewers are often pretty leaky actually. A lot of early sewage systems have combined sanitary and storm sewers, but around the 1940s, separating santiary sewers from runoff drains became common for new systems. Even in separate systems, most sewage systems see an increase in volume during the rainy season, and it's not because people pee more when it's wet outside (maybe they do, but...). Ground water leaks into the sanitary sewers; and presumably sewage leaks out of the pipes into the ground at times. As long as the slopes are reasonable, and there is free flow, leaks aren't a big deal... but leaks and gaps do allow for root intrusion which leads to clogs. Typically municipal sewer lines are pretty deep and tend to be towards the middle of the street which makes it harder for plants to get in there, but some plants are pretty persistent.
Here's an EPA manual from 1971, Prevention and Correction of Excessive Infiltration and Inflow into Sewer Systems. The key thing here is that the goal isn't to eliminate infiltration, but to eliminate excessive infiltration; it's all tradeoffs.
They've had pipeline 'pigs' for quite a while that at first we're just solid plugs separating product but have gotten to be fancier and fancier. I think a drain robot would be like that.
Pipelines are cool. I don't have any direct references to give you, but you can search-engine for some interesting stuff. I did work for a petroleum distributor years ago and got to talk people w/ pipeline experience.
An interesting anecdote I can relate is learning abut "transmix", AKA "slop". I worked on a logistics planning app (a really, really fun mix of traveling salesman and bin packing). I saw an entry for "slop" in the pricing feed from an exchange. This caught my eye and led me to talk to one of the "pipeline guys" about what "slop" might be (spoiler - it's a mix of pipeline products that happens when the product in the pipeline is changed) and why one might want to buy "slop".
I think I bought mine for $150 including the battery and charger. Money well spent, if you ask me (certainly cheaper than hiring a plumber). Before that I had a manual version similar to the one you linked to, but it just didn't cut it in my last case of a clogged kitchen drain.
The nice thing about the automatic version is that you can go in/out and clockwise/counterclockwise independently and with a simple switch, which makes it easy to route through complicated pipe geometries without getting stuck, and you don't even have to apply much force because the machine does that for you.
You can pop the handle off that Ridgid one and there's a hex bit you can hook up to your existing drill. It's admittedly a bit wonky to operate like that, but for a single family home it's mostly workable.
I'd imagine there are multiple approaches to this e.g. shredding heads which break up soft material in front of the bot, or multi-robot configurations for snaking material.
There might be an efficiency gain to be had in overall city plumbing by breaking up detritus which has gotten stuck in the pipe.
I was observing an army of 20-25 men struggle to resolve a broken main the other day. They had to bring out a gigantic vac truck to pull the water out of the work pit fast enough to get back in there.
If you offered them the use of your robot, you would probably be at risk of bodily harm.
Also, fun fact about Boston (MA?) construction laws. Per block, a crew is only allowed two steel plates...
In the past year, the gas line and water main on my street has been replaced. Which has resulted in 6 excavations of the street at excruciatingly slow and loud pace with the vac truck. They excavate once to transfer each finger connection (to the houses) and attach the feeder to a temporary pipe, refilling their progress each day. Once a segment (about a city block or two) been transferred to the temporary line, they excavate again to remove the old line, refilling each day. Finally they lay the new line and connect the finger lines to it.
If you can only cover two steel plates worth of trench overnight, there isn't a chance for the gas team to coordinate with the water team.
With better laws this would have taken a 1/3rd of the excavation, possibly a 1/6th of the excavation. Since excavation and refilling were most of the work in any day, this should also have led to the same cost decrease.
I don't know the exact law or regulation, but I have heard about it from multiple sources, and do intend to being it up with city council.
The giant vac truck generally is for safe digging around other unknown utilities. Sometimes this is combined with a water jet that loosens soil, and the vac sucks up the soil and water.
If they wanted to just drain an excavation, they would use a regular trash pump (capable of handling solids/sand) and run the discharge hose to a nearby stormdrain.
That I've heard, the best way to minimize fatbergs would be to put a hefty tax on "flushable" wipes. Unfortunately, the companies which manufacture them all know that breaking consumers' fell-good delusions (that the wipes are guilt-free flushable) would tank their sales. And politicians are always happy to let lobby-savvy corporations externalize their costs onto the public purse.
The important thing would be to block them from replacing "flushable" with something similarly deceiving. Ideally, they'd have to replace it with a big, scary warning label - about how flushing those wipes could stick you with a flood of backed-up sewage and/or a 5-figure plumbing or septic system repair bill.
Prevention is not the cure to the tragedy of the commons, we always need to be able to react. I don't pour oil down my drain, but the rest of the building does, which is how my six-meter wire won't do jack.
A laboratory environment which is devoid of any resemblance to the real world will yield you different results compared to had you designed and built first for the environments you will encounter, would you agree? And these results could have capabilities not transferrable between different environments.
I try to raise these questions in good faith: For example, are wheels the way to go at all for filthy pipe environments with many sticky and tangly hazards, or do we perhaps have to explore more snake/worm form factors? If we design for the clean environments, all the magical "cost savings for infrastructure restoration" accounting you can do will never materialize.
You are right, in the filthiest environments nothing else can be as performant as a worm/snake-like robot, even if such robots are inferior to those with wheels or rotary propellers in nice tidy environments.
Moreover, instead of making a robot with arms, which are useful for work, but which are an impediment for moving in a filthy environment, it is better to send multiple vermiform robots, which are designed such as after reaching their destination they are able to cooperate in such a way as to act like a robot with multiple arms (i.e. they should be able to attach to anything in the environment or to another robot with both the anterior end and the posterior end, like leeches).
We do not need federated messaging at the consumer app level, we need a replacement that's available at the cellular network level (just like SMS). RCS (https://en.wikipedia.org/wiki/Rich_Communication_Services) is trying to do this, but it might be too little too late.
In practice RCS is entirely run by Google outside China, the path to federation was killed around 2019 when Google decided every MNO should eventually move to Jibe if they wanted access to a global interconnected RCS, same on the client side.
I don't think it's too late as iOS finally supports RCS. But so far Google hasn't shown willingness to let unsanctioned clients connect to Jibe.
And even within the Google ecosystem, RCS access can be iffy. It was working fine on my Pixel for months, then switched its status to "Setting up..." and hasn't worked for months since then, despite me trying All The Things suggested on various fora short of factory resetting my phone.
Jibe is the only RCS backend in 180+ countries. The few MNOs that had deployed third party solutions (mostly from Mavenir and WIT) eventually killed them off once Google made clear they weren't interested in a federated network anymore.
The US was actually the only market where a federated RCS was tried at scale for a few years (the CCMI) but all carriers eventually gave in as the UX was poor and unreliable.
To my knowledge there are only two other non-Jibe RCS "islands": China (that runs RCS solutions from national providers like ZTE) and +Message in Japan. +Message is on its way out, as carriers are now pushing subscribers to Google Messages and Jibe, anticipating the iOS support.
And Apple is in on it: MNOs don't have a choice here, they now need formal agreements with Google (Jibe is paid through RBM revenue share) and IMS configuration and (de)provisioning workflows that are sanctioned by Apple and de facto tested only against Jibe.
Apple's communication around E2EE in UP 3.0 is also directly following Google's work on replacing their ad-hoc Signal implementation by MLS.
Except RCS doesn't work on anything except phones, while XMPP works perfectly fine everywhere. IM was vastly better on computers back when you could use applications like pidgin or kopete.
The time when XMPP was supported by google (and Facebook IIRC?). Running jabber for small groups was pretty simple, and you had Adium and pidgin, both were simple to use and just neat software
The problem is mobile, and specifically the need for push notifications to have reasonable battery life. The traditional model that desktop IM clients use, where they have a permanent connection to the server, is not viable on mobile. But push notifications require you to design your protocol around them and lock you into the corresponding provider (i.e. Google or Apple, depending on the platform).
I'm not familiar with real world home firewall behavior, but shouldn't you be able to leave a TCP connection open/idle with no keepalive for minutes if not hours? I'm skeptical of the battery life argument around notification lockin, particularly when I see how much Android devices light up a pihole.
I don't claim to understand the specifics, but I was a heavy user of custom XMPP clients on early Android phones, and they did require a persistent notification to keep the app (and thus the connection) alive, which did translate to measurable battery impact. My understanding is that the built-in notification manager helps with this by multiplexing and batching everything.
Your fixation is a result of the fact that interacting with LLM coding tools is much like playing a slot machine, it grabs and chokeholds your gambling instincts. You're rolling dice for the perfect result without much thought.
That's a better description than what I came up with, "Tiktok for engineers". LLMs probably compound the issue, with that hope of a magic outcome. Though I've had many problems pre-LLM where I was plowing through it myself and couldn't let up...
Is there any progress toward more deterministic AI? Like seeding with predictable values or a nanny AI that discards hallucinations? I know the smartest people in the world are working on this stuff so I’m sure they’ve thought of everything before me but I don’t know where to seek out layman’s news on cutting-edge AI developments that aren’t just “we threw more compute and tokens at it”.
Over the last year and change I've generated 70 thousand images on civitai.com, a website that hosts neural net image generation models. (For porn, obviously)
Twenty out of a hundred gens are malformed horrors. Seventy out of a hundred are boring or cack-handed. Nine are interesting and worth exploring. And one out of a hundred I would say the algorithm accidentally produces real art.
Roll that one out of a hundred too many times when you're just starting out, and, well, you end up like me.
It's true you're still working, but it's a different, more distracted effort: you put the LLM on something for a while and then come back.
Sometimes it does it right, some times not. I can see the relation to gambling if, say, it does it right 50% of the time. If I had been taking a more scientific approach to the problem and had a clear direction of what I wanted to test, I suspect I wouldn't have gotten quite as "stuck".
Does that mean that a physics engine written with these operations will always compile to yield the same deterministic outcomes across different platforms (assuming they correctly implement (or able to do so) algebraic operations)?
It's more like the opposite. These tell the compiler to assume for optimization purposes that floats are associative and so on (ie. algebraic), even when in reality they aren't. So the results may vary depending on what transformations the compiler performs – in particular, they may vary between optimized and non-optimized builds, which normally isn't allowed.
> These tell the compiler to assume for optimization purposes that floats are associative and so on (ie. algebraic), even when in reality they aren't.
I wonder if it is possible to add an additional constraint that guarantees the transformation has equal or fewer numerical rounding errors. E.g. for floating point doubles (0.2 + 0.1) - 0.1 results in 0.20000000000000004, so I would expect that transforming some (A + B) - B to just A would always reduce numerical error. OTOH, it's floating point maths, there's probably some kind of weird gotcha here as well.
Pretty sure that’s not possible. More accurate for some inputs will be less accurate for others. There’s a very tricky tension in float optimization that the most predictable operation structure is a fully skewed op tree, as in naive left-to-right summation, but this is the slowest and least accurate order of operations. Using a more balanced tree is faster and more accurate (great), but unfortunately which tree shape is fastest depends very much on hardware-specific factors like SIMD width (less great). And no tree shape is universally guaranteed to be fully accurate, although a full binary tree tends to have the best accuracy, but has bad base case performance, so the actual shape that tends to get used in high performance kernels is SIMD-width parallel in a loop up to some fixed size like 256 elements, then pairwise recursive reduction above that. The recursive reduction can also be threaded. Anyway, there’s no silver bullet here.
I think a restricted version might be possible to implement: only allow transformations if the transformed version has strictly fewer numerical rounding errors on some inputs. This will usually only mean canceling terms and collecting expressions like "x+x+x" into 3x.
In general, rules that allow fewer transformations are probably easier to understand and use. Trying to optimize everything is where you run into trouble.
Kahan summation is an example (also described in the top level article) of one such “gotcha”. It involves adding a term that - if floats were algebraic in this sense - would always be zero, so ffast-math often deletes it, but this actually completely removes the accuracy improvement of the algorithm
Buth for Forth you can have a totally working software floating point
made from the people whose later would set the IEEE standard.
Think about very small microcontrollers without FP in hardware, you can be sure that a software FP implementation will perfectly work under the standard thresolds.
Okay, I guess? I appreciate having a well-verified library when I can't have floating point hardware, but I'm never in that situation and I really don't see how it's relevant to this discussion. Any floating point implementation is going to have rounding problems, including IEEE. The example above is IEEE.
No, there is no guarantee which (if any) optimizations are applied, only that they may be applied. For example a fused multiply-add instruction may be emitted for a*b + c on platforms which support it, which is not cross-platform.
I firmly believe that differentiable logic CA is the winner, in particular because it extracts the logic directly, and thus leads to generalize-able programs as opposed to staying stuck in matrix multiplication land.
If you look at the learned gates, it does not directly extract the underlying rules of Conway's game of life. It has many more gates than are necessary and they have the same complex, uninterpretable structure you see in a neural network.
The training method they're using is the same as used for quantized neural networks. Your 'neurons' being logic gates doesn't mean you're doing logic, it's still statistics.
Talking about unwrapping: I’ve been using a rather aggressive list of clippy lints to prevent myself from getting panics, which are particularly deadly in real-time applications (like video games). unwrap/expect_used already got me 90% of the way out, but looking at the number of as conversions in my codebase, I think I have around 300+ numerical conversions (which can and do fail!)
This is nice, but fairly miserable to deal with in in-module unit tests, IMO.
We get around it by using conditional compilation and putting the lints in our entrypoints (`main.rs` or `lib.rs`), which is done automatically for any new entrypoint in the codebase via a Make target and some awk magic.
As an example, the following forbids print and dbg statements in release builds (all output should go through logging), allows it with a warning in debug builds, and allows it unconditionally in tests:
Yeah that is nice too, and that should also skip all the test code. I think all the clippy warnings on tests for unwrapping and such when working locally would bug me though. And at least the eglot LSP client tends to get bogged down when there are more than a thousand or so clippy warnings/errors, I have found.
All but one of these come from the restriction[1][2] lint group.
I try to remember to look at new restriction lints with every Rust release. For example, here's what new with 1.86.0[3]; the `return_and_then` lint looks pretty nice.
n.b. no one should enable all restrictions lints— some are mutually exclusive, some are appropriate for specialised circumstances like `#[no_std]`. But I find them helpful to keep a project away from the wild parts of Rust.
It was the first time I set it up, then I went through every single instance and refactored with the appropriate choice. It wasn't as tedious as you might imagine, and again, I really don't have the option of letting my game crash.
I think the only legitimate uses are for direct indexing for tile maps etc. where I do bounds checking on two axes and know that it will map correctly. to the underlying memory (but that's `clippy::indexing_slicing`, I have 0 `clippy::unwrap_used` in my codebase now).
If you begin a new project with these lints, you'll quickly train to write idiomatic Option/Result handling code by default.
yoink (although I will probably allow expect - having to provide a specific message means I'm only going to use it in cases where there's some reasonable justification)
reply