chaboud

Most human drivers (not all) know to nose out carefully rather than to gun it in that situation.

So, while I'm very supportive of where Waymo is trying to go for transport, we should be constructively critical and not just assume that humans would have been in the same situation if driving defensively.

I've even found sonnet and opus to be quite capable of generating json describing nodes and edges. I had them generate directed acyclic processing graphs for a GUI LLM data flow editor that I built (also with Claude - https://nodecul.es/ if curious)

The bio-oil plasticizers also migrate out more quickly in thermal cycling than the old dead dinosaurs approach. Hilariously, when I asked my mechanic about getting an M5, he laughed and explained that the radiator components are known to turn brittle and crack after 5-6 years because of this.

(I don't envy automotive folks. The stuff they have to deal with is next level.)

I've pulled some tricks like "object-pre-pufficiation" (low-frequency model manifold encapsulation, then following the same bones for deformation) mixed with normal recording in shadow layers (for realtime work on old mobile hardware), but, these days, so much can be done with sampling and proper ray-tracing, the old tricks are more novelty than necessary.

It still pays to fake it, though.

https://github.com/mavdol/capsule

(From the article)

Appears to be CPython running inside of wasmtime

And this is a bit of a sliding scale. Of course users want the best possible answer. However, if they can get 80% (magic hand-wavey fakie number) of the best answer on one second instead of 20, that may be a worthwhile tradeoff.

Knowing that you know something by teaching is Feynman's method of understanding. Basically, on scanning, I don't particularly disagree with the content of the post. However, treating these things (many of which regularly show up here on HN) as being due to "14 years at Google" is a little misplaced.

But, hey, it's 2026, CES is starting, and the hyperbole will just keep rocketing up and out.

https://thedreydossier.substack.com/p/trump-isnt-building-a-...

https://dl.acm.org/doi/10.1145/1165555.1165556

Aggregability is NP-Hard... Useful the next time someone insists that it's possible to find a "perfect" model for a non-trivial ML problem. (I get this ask 1-2 times per month.)

I'm excited to see this option become more broadly available. The ability to precisely target and illicit an inflammatory response is impressive, and Whipples are no joke.

Another is broadband deployment. Choice is low in many parts of the country, and bundled service offerings are frequently priced near the "internet only" offerings to nudge customers into a "might as well" posture.

https://www.ecfr.gov/current/title-17/chapter-II/part-240/su...

Note: I am neither a lawyer nor in financial circles, but I do have an interest in the effects of market design and regulation as we get into a more deeply automated space.

"Scared them shitless" in faux franglais.

Probably something like this would be close to the same colloquial meaning (I'm not familiar with any pants-shitting slang in French): EncroChat leur a foutu les jetons de ouf.

(closer to "scared the hell out of them")

Funny enough, though, it wasn't until I moved here 15+ years ago that it struck me how odd it is to call it "the Bay Area" and expect people to know what that means. Nonetheless, sportscasters do it. Musicians do it. All other bay areas are just areas around bays...

There's one exceedingly simple answer:

Keep the penny (possibly a new one that is cheaper to make).

We're basically breaking into jail on this one, creating more problems than we're solving.

Intentional or not, the linked article opens with a comically untrue statement, that, because it is verifiably false, doesn't even escape as puffery. When I encounter this sort of grandstanding in framing (generally from junior engineers or fresh-from-school product managers), I spell out just how negatively such misstatements harm the point being made.

It's a turn-off for readers, and it's unnecessary.

"You may be used to seeing graphs like..." or "In grade school, we learned to graph like..."

would probably be more useful than dismissal of the history of visualization of implicit functions. Hopefully, next time, the author will be a bit less grandiose.

That said, I agree with the point and expose as much as possible in the URL, in the same way that I expose as much as possible as command line arguments in command line utilities.

But there are costs and trade offs with that sort of accommodation. I understand that folks can make different design decisions intentionally, rather than from ignorance/inexperience.

It's a simple quick-and-dirty vibe-coded "virtual costume" static site that hopefully makes up for having phoned it in this year.

https://github.com/chaboud/costuma is the repo, which includes the code, prompts, conversations, plans, etc.

For building things like this, I'm finding these tools very effective, occasionally incredibly frustrating, and always intriguing.

And I'm perfectly happy listening to Toxic by Britney Spears on phone speakers while drinking Miller High Life on a sunny day in the park, hopping in a banged up Miata to rip a donut in a parking lot.

Don't let fear of "spoiling" things keep you from ever growing your experiences. People tend to have a gravity for the things that matter to them.

And don't let knowledge of fancy things keep you from finding joy in the basics.

That said, the non-tech-executive/product-management take on AI has often been an utter failure to recognize key differences between problems and systems. I spend an inordinate amount of time framing questions in terms of promises to customers, completeness, reproducibility, and contextual complexity.

However, for someone in my role, building and ideating in innovation programs, the power of LLM assisted coding is hard to pass up. It may only get things 50% of the way there before collapsing into a spiral of sloppy overwrought code, but we often only need 30-40% fidelity to exercise an idea. Ideation is a great space for vibe coding. However, one enormous risk in these approaches is in overpromising the undeliverable. If folks don’t keep a sharp eye on the nature of the promises they’re making, they may be in for a pretty wild ride; with the last “20%” of the program taking more than 90% of the calendar time due to compression of the first “80%” and complication of the remainder.

We’re going to need to adjust. These tools are here to stay, but they’re far from taking over the whole show.

I recently vibe coded a video analysis pipeline with some related arduino-driven machine control. It was work to prototype an experience on some 3D printed hardware I’ve been skunking out.

By describing the pipeline and filters clearly, I had the analysis system generating useful JSON in an hour or so, including machine control simulation, all while watching TV and answering emails/slacks. Notable misses were that the JSON fields were inconsistent, and the python venvs were inconsistent for the piped way that I wanted the system to operate with.

Small fixes.

Then I wired up the hardware, and the thing absolutely crapped itself, swapping libraries, trying major structural changes, and creating two whole new copies of the machine control host code (asking me each time along the way). This went on for more than three hours, with me debugging the mess for about 20 minutes before resorting to 1) ChatGPT, which didn’t help, followed by 2) a few minutes of good old fashioned googling on serial port behavior on Mac, which, with an old sitting on the shelf Uno R3, meant that I needed to use the cu.* ports instead of tty.*, something that Claude Code had buried deeply in a tangle of files.

Curious about the failure, I told Claude Code to stop being an idiot and use a web browser to go research the problem of specifically locking up on the open operation. 30 seconds later, and with some reflective swearing from Opus 4.1, which I appreciate, I had the code I should have had 3 hours prior (along with other garbage code to clean up).

For my areas of sensing, computer vision, machine learning, etc., these systems are amazingly helpful if the algorithms can be completely and clearly described (e.g., Kalman filter to IoU, box blur followed by subsampling followed by split exponential filtering, etc.).

Attempts to let the robots work complex pipelines out for themselves haven’t gone as well for me.

One funny thing about software is that beautiful things can emerge from the most unexpected places. I appreciate that there are folks out there with the bravery to share their journey.

White balance is hard, in part, because the sensitivity bands of our vision and the camera sensors do not align. Take a look at fluorescent (or, better still, sodium vapor) light spectra for clarity on why this is a massive pain.

My first boss (a CTO at a start-up) drilled this into us. What you know is far less valuable than how you learn/think and how you function on a team.