Adafruit Receives Demand Letter from Fenwick Legal Counsel on Behalf of Flux.ai
blog.adafruit.com448 points by semanser 7 hours ago
448 points by semanser 7 hours ago
hi everyone, its me 'ladyada. we're very much looking forward to telling our story, i have reached out to the founder of flux.ai (Matthias Wagner - Founder & CEO at Flux), in hopes we can resolve this together and set a good example for the community. looking forward to maybe seeing this resolved on a podcast together, or something
(somewhat) unrelated to this kerfuffle, but I can say I've ordered thousands of dollars of stuff from Adafruit, and the quality of the electronics, the speed of shipping, the prices, and the customer service have been consistently outstanding.
Hope common sense prevails and Adafruit can go back to doing what it does best instead of dealing with this (IMO) distraction.
Adafruit's documentation and software maintenance is also top notch. I just built a new project using an ancient, no-longer-sold Adafruit PiTFT Plus which I had in my parts bin. Their software installer worked great on latest PiOS, and their data sheets had all the dimensions I needed. Outstanding.
Good luck! Big fan of your work for many, many years. Thank you for the amazing resource that is Adafruit.
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 there now. Placement is probably the big issue that needs to be solved now. I could only get about 80% of what I wanted together with my hacky workflow.
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.
But at least their priorities are in order. How do you overcome those showstopping challenges & have more time to meet customers?
Lawfare!
> 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 feed it into more deterministic tools.
I also note that it's very easy to waste more than $100 in electronics once you start actually manufacturing bad PCBs.
> 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.
I've been frustrated with Copilot in this regard.
I work on a large C++ codebase, with large files. Human developers jump around between files with the Visual Studio fuzzy search, set breakpoints to trace execution in the Debugger, use the IDE's refactoring tools.
Microsoft's answer to this was to just ... expose none of this to their Agent Mode!? Replace the working semantic autocomplete with fucking lies!?
Maybe it's changed, I haven't been paying that much attention after bouncing off of this. I've gotten mild acceleration from using gptel-mode in emacs, manually adding references to context, and having models do various mechanical transformations on code. And I've even had some limited success writing tools for it to do LSP lookups.
It frustrates me too, it really feels like the next breakthrough will be when someone gets agents working "natively" with LSP on large code-bases.
Anthropic added LSP support to claude-code, but the current implementation is worse than useless, because any changes aren't reflected fast enough, so it's constantly working on outdated views / compilation caches, and it gets in a right muddle between its "internal" state / understanding in context, the real-world file, and the LSP.
If it could just leverage LSP to apply refactorings it would be amazing, but it feels like the LSP can't keep up, and I don't know if that's an LSP problem or a claude problem.
So we binned the LSP plugin and we're back to watching a machine find/replace, because while waiting on that is slower than LSP, it's a "Action => Wait" which the tooling understands, while LSP is "Possibly Wait for LSP to catch up => Action" which it doesn't understand nearly as well.
I suspect the LSP plugins also need better skills that pair with them so it reaches for them more often.
It hurts my soul to see it reach for find/replace to rename a class, complete with mistakes made in complex solutions where you might have name clashes in different namespaces. Something the LSP handles without problem, but can trip up an LLM.
I wonder, is the problem here that LSP is updating too slow all the time? Or just that there’s a chance it will update very slow, and you never really know if you’ll hit that chance, so your model always has to do the “long time wait” just in case? It seems like it ought to be possible for LSP to report that it is still processing, in the latter case, somehow…
I'm not an expert, but my reading of the spec is that LSP can handle generic $notifications, but there isn't a specific standard for readiness reporting beyond "Initialize / Initialized", which isn't suitable for monitoring on-going staleness or readiness post-file-detected change, the spec has that as a single first-time initialization.
There are notifications (i.e. `textDocument/didChange` ) that you can send to the LSP to help it along, but again you might end up racing the notification from the client making the change and any file-watchers you might have running.
I suspect the answer will come in the form of some kind of more powerful LSP implementations with generous memory caches so that disk changes are just another buffered input that can be disregarded if already stale, no longer seen as the source of truth, and the LSP becomes the real source of truth, so everything can coordinate through it, operating mostly out of memory.
Another avenue for better success will be more research into faster compilation and better incremental compilation for languages with slower compilation.
Maybe one day we'll even get AI agents directly manipulating syntax trees, and the code to get there being written back as merely a side-effect, but that seems like sci-fi compared to the current state of play. LSP is still very document based, and of course LLMs are also trained on oodles of source.
I work in Unity and I got frustrated with Claude constantly doing gross bash/grep/awk/sed/grep nested loops that took forever that I finally described (and had Claude implement and install) a tool that could, in a single pass, gather all this info from a Unity forest of scenes at once and answer all the questions Claude ever wanted to ask about a Unity project in a single pass that takes 50ms instead of 10 30 second iterations. It still took a lot of coaching to get it to actually use this tool, but it seems like I’ve convinced it.
if it helps, I've found that using context (Claude.md etc) is way less effective for this type of pattern compared to using PreToolHook to capture "bad patterns" and either transparently rewriting them to "do the right thing" if that is possible statically, or if not then rejecting the tool use with a message that tells the agent "how" to use the intended tooling itself.
tool_call is just a fancy wrapper to a black box that executes console commands. Said commands are now the actual backbone of all agentic AI, It feels like the linux people are incredibly vindicated in the single responsibility principle
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.
This type of laziness isn't novel.
Check out left pad or the two dozen other "utility" packages that could be done in a single line of code.
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.
What would be a better way to incorporate AI as a spell checker?
In comparison to non-AI traditional tools, AI has the advantage of "understanding" the text, reducing the number of "stupid" mis-corrections. And its spelling correctness is usually already impeccable, so what is there to gain by interfacing it with traditional solutions, and how can it be achieved?
AI can’t really spell check without risking changing the meaning of sentences. Spell checking was a solved problem before this.
Spellchecking is absolutely not a solved problem. I immediately disable spellchecking on every avenue it tries to approach because managing a bunch of dictionaries on every browser/device/application that has its own spellchecker for some godforsaken reason to not have squigglies spammed over every piece of jargon, slang, and slightly atypical spelling is incredibly annoying. I don't know how effective LLMs are, but it's difficult to imagine they can be worse than the existing regime, which is embarrassingly bad for the decades it's been around.
An interesting idea I saw long ago in some book (I thought it was K&P's "Software Tools," or my second guess was K&R1, but neither of those panned out — a strong Mandela effect) was the clever idea of a whole-document spellchecker that works purely probabilistically, by histograms: you feed it a document, it tallies the trigraphs, and any trigraph that appears only rarely is flagged as a likely typo. This approach lets through unknown-but-realistic words like "antithematory" while flagging unrealistic words like "prisencolinensinainciusol" (because of its unlikely "ciu" and "ius" clusters) and "antthemaory" (because of "ntt" and "aor").
To make this approach work better, feed it a bunch of English text (or whatever language your document is in) before the document you really want to "spellcheck."
Essentially this isn't a spell "checker" so much as a spell "linter" — it looks for antipatterns statistically associated with bugs, and reports the patterns for further investigation.
If anyone knows where this trigraph-based "spellchecker" was first presented, I'd love to find out again.
I like that. Might some of that logic have made it to consumer word processing programs?
Human copy editors are less than perfect too. I hired one copy editor who I could not trust to be the last person who touched a document before it went out.
I had a friend who wrote an article for the New York Times: the article made a lot of sense before she submitted it, but it was edited for length and style and it definitely read like a New York Times piece but didn't completely make sense.
Only if the problem is declared to be whatever it is that spell checkers solve. As the classic joke goes, "Me spell chucker work grate. Need grandma chicken."
>Only if the problem is declared to be whatever it is that spell checkers solve.
The problem being misspelling, hence, "spell checker". Like, this seems pretty straightforward? Grammar checking if you cannot use the language properly is a pretty different problem space, and indeed has long existed and is exposed as a separate thing. And not just in fancy word processors either, if you go to something as simple as macOS TextEdit you'll see separate check boxes for "Check spelling as you type" vs "Check grammar with spelling". If someone wants to try out using LLMs for grammar no problem, but spell checking is purely about the mechanical and, importantly, deterministic aspect of typos or outright non-words.
>As the classic joke goes, "Me spell chucker work grate. Need grandma chicken."
There is a genuine touch of irony/meta in you using that here in this context. That sentence has no misspelled words, and importantly gets across the exact humorous meaning the human who wrote it intended. The joke literally only works because a human was able to make creative use of language. If you had an LLM agent posting for you to HN and it automatically changed that to:
>As the classic joke goes, "My spellchecker works great but could use some grammar checking."
Well, where would the joke be now!? This goes to the exact concern people have with powerful non-deterministic meaning-changing tools replacing deterministic meaning-preserving ones.
I just fed this entire thread (excluding your comment pointing out the joke, and the text mentioning that it was a joke) to an LLM, and it did better than the dictionary spellchecker: corrected one real error, left my "squigglies" alone which was attacked by squigglies with the old-hat spellchecker, and specifically noted, without any prompting in that direction, that it left the joke spelling unchanged. It did not rewrite any sentences. I'm all for determinism where deterministic tools work, but the current implementations are so bad I can't blame people for turning to a non-deterministic program if it's still better on average.