Live data from Hacker News

Adafruit receives demand letter from Fenwick legal counsel on behalf of Flux.ai

blog.adafruit.com

191–200 of 300 posts

Re: Adafruit receives demand letter from Fenwick legal counsel on behalf of Flux.ai

#191
post #47

Earlier quoted context omitted.

> There are some AI-driven autorouters out there now. Placement is probably the big issue that needs to be solved now. Interesting that within an IC this is basically "solved", or at least properly automated with classical numeric techniques such as simulated annealing. I would have thought there's a big opportunity in a mixed-technique approach, where you use AI to extract unstructured data from datasheets and then…

> mixed-technique approach I think my biggest annoyance with the way we rolled out AI is that nobody seemed to want to use it to augment already working solutions. Just throw everything out and have an LLM do it instead.

Hey man, speak for yourself.

It's never occurred to me to even try getting an LLM to design or layout a circuit for me.

Instead, I have dozens or hundreds of chats in my history where I debate the merits of different parts for different tasks and scenarios, the nuances of decoupling strategies (package size vs deregulation), work out resistor network ratios from the reels I have on hand.

Then being able to feed an LLM a datasheet and have it write a custom driver against the registers I need so that it does exactly what I want without the cognitive overhead of a buggy package with someone else's strong opinions about how a part should be used is amazing.

Frontier models are incredibly good at electronics, and it's got nothing to do with what happens inside the EDA.

Re: Adafruit receives demand letter from Fenwick legal counsel on behalf of Flux.ai

#192
post #93

Adafruit probably did a review of AI PCB tools. I've used Flux.ai before; it was a pretty bad experience. After about 50-100$ in tokens a couple of times, I couldn't get more than a couple of simple components on the schematic. And not in sensible positions. The product just grinds tokens for little return, in my opinion. I had far better luck wiring together KiCad MCP, SKIDL. There are some AI-driven autorouters out…

This is exactly my experience, wasted $60 trying to get it to make something. The founder sent an automated AI email about setting up a time to meet and go through it then ghosted me at the meeting time.

Yes but look, they set up meetings so they're listening to customers, like all good founders /s

Re: Adafruit receives demand letter from Fenwick legal counsel on behalf of Flux.ai

#196

Earlier quoted context omitted.

Nor the famed Good Will Hunting and Argo actor and director, Ben Afflux

Nor the Cartoon Network show (and later movie) Aeon Flux.

Nor the streaming service Net Flux

Re: Adafruit receives demand letter from Fenwick legal counsel on behalf of Flux.ai

#197
post #60

Earlier quoted context omitted.

I recently saw a Claude skill that used Claude, with no tools, as a spell checker. I wanted to hurl my laptop out to the window.

Isn't this pretty much why language models were invented? Pasting something directly into the chat interface seems weird, but if you could somehow just see where P(token | context) falls off a cliff, that's a pretty good hint that your writing has problem.

Yeah, but for this use case you don't need Claude. You probably want a tuned lightweight small model that can run locally.

Even Haiku is massive overkill for this use case.

Re: Adafruit receives demand letter from Fenwick legal counsel on behalf of Flux.ai

#198
post #33

Earlier quoted context omitted.

They vibe coded their system and it showed Adafruit something? Or showed some information with trivial prodding? Sounds like your average cross-tenant leak. Maybe showing more than intended or some caching issue. Many options some not really not fault of Adafruit.

Or someone found server.domain/path/subdirectory/resourceX and was like "shit, I was hoping to find resourceY but I can't find a link to it, I wonder if I just click in my address bar and change the X to a Y", and voila, resourceY is right there. To some of us, this is elementary navigation. Like going up the stairs if the elevator is out. Often it's faster than waiting for the damn elevator, too. To others, it's cyb…

It has a name in the security industry, Insecure Direct Object Reference (IDOR) [1]. Somewhat related to Path Traversal [2]. Unfortunately CFAA is very broad and can be (mis)interpreted in wild ways.

[1] https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire... [2] https://owasp.org/www-community/attacks/Path_Traversal

Re: Adafruit receives demand letter from Fenwick legal counsel on behalf of Flux.ai

#199
post #51

Earlier quoted context omitted.

Yeah this stuff isn't even realistic as well. A number of years ago I was working on something professionally and there was a problem. Only about 1 in 5 boards assembled wouldn't crash the CPU. After much debugging it turned out one of the ICs had an open collector output and it wasn't loaded correctly with a pull up resistor. This caused a cascading failure, held the bus up when initialising the hardware which hit t…

I'm with you on the complexity of debugging hardware, as I've been there too. But I will say, automatically adding pullups to floating pins is something that an automated process could succeed at. Not first gen of blindly throwing an LLM at circuits and hoping, but perhaps a later improvement that uses metadata about parts. Perhaps curated metadata about parts, or always starting with a reference design and tweaking…

> always starting with a reference design and tweaking from there.

That's just basic design sensibilities.

Re: Adafruit receives demand letter from Fenwick legal counsel on behalf of Flux.ai

#200
post #188

Earlier quoted context omitted.

> But this is a logic fail is it not? It is not. The LLM approach is not dependent on system configurations. You can expect that it probably works the same from any device or application, because it can surmise slang/jargon from training and context rather than needing to be fed every little individual case as a per-user configuration. There are advantages to making a program more sophisticated than a literal == chec…

> The LLM approach is not dependent on system configurations How is it not dependent? Like, help me out here: I'm writing something up in vim on my FreeBSD system using the built-in dictionary capability, maybe I've got grammar too with LanguageTool via the ALE plugin. I've added various words to my good words list over time. I save it to a network drive and want to keep working on it and do some graphical formatting…

You seem to be pointing out that spellcheckers are more mature and currently have more system integration, but it's not inevitable that will always be the case. One could suppose the LLM spellchecking is eventually integrated at the OS-level, and the way it would be superior to existing OS-level spellcheckers is that the program is sophisticated enough to not need to maintain and sync a dictionary around because it simply spellchecks effectively without one (and there's no reason it couldn't also use a dictionary augmenting its context, if you had some really bespoke conditions that warranted one).

> But how do you know what the "average" is? You can't get that from a single shot.

I don't know what the average is. I never made a claim that LLMs are categorically better than spellcheckers; I simply said it's hard to imagine they'd be worse, given how bad spellcheckers already are, and that I understand why people would be willing to give a non-deterministic tool a try, contrary to it being stated like doing so was the dumbest thing imaginable and that spellchecking was a 'solved problem'.

You're correct that one shot is not a statistical analysis, but multiple people were throwing around assertive claims that LLMs rewrite entire sentences and change their meaning when prompted to spellcheck, or that LLMs were incapable of handling a joke with intentional mispellings being integral to the joke, both of which seemed incorrect on their face to me, so I gave it a try. LLMs are typically conditioned to a high degree of mode collapse, so I do expect that if I retried the same prompt and context on the same model 100 times, it probably would give approximately the same output at least 90/100 times, if not 99, but I'm not presenting a thesis here.

> And what's the upside vs downside of false positives or false negatives or meaning changes/hallucinations?

Sure, these are valid considerations. I would not, under any circumstances, let an LLM touch my legal documents for any reason. However, the stakes for spellchecking an internet comment are non-existent, so one could easily imagine trading the downsides for the benefit of not being nagged by squigglies.

> And you clearly have an intense personal issue here around grammar/spelling

I really don't, actually. As I mentioned, I disable spellcheckers on sight, and I don't use LLMs for spellchecking myself. I rely on my own two eyes for spellchecking, and sometimes I miss things, which is an outcome I'm okay with. Spellcheckers, then, are not something I ever think about, beyond the time it takes to disable them after being nagged on a new device or application. I do take offense to calling such a laughably poor state of technology a "solved problem", though, and the sneering at people attempting to find new solutions to it. There is absolutely nothing wrong with attempting to iterate on a bad status quo.

I would also note that I think the non-determinism could also be solved to an appreciable degree by simply having the integrated LLM tool offer suggestions, which require human approval to correct, much as current squigglies operate but perhaps with a lower failure rate on average. Or not! But it's an area I can see value in exploring, anyways.

Post reply on HN