A confession
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 cybarrrr-criiiimeeee!!!!!!11111one
Mind you there can be nuances, but that quote is like saying "I took their stuff, but it was poking out of their pocket."
Of course, we don't yet know the specifics of this particular case, but I'm willing to lean towards the people receiving legal letters threatening CFAA action until there's more information.
Now it is bit questionable should you check things like this during evaluation or not. Strict legal reading probably not. With reasonable customer relations you thank them and put it on top of the priority list. Unless they clearly enumerated everything they got their hands on or tried to run more real scans.
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.
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.
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.
Edit: it’s almost assumed at this point but for completeness Claude / Codex were the ones driving the OO python code and datasheet research and parsing.
Then we got LLMs which will make a good parody of anything and occasionally get it right.
Is this common? When I try out new AI tools, even as person who is financially independent, I load up maybe 10-20 USD worth of tokens, and if I don't get anything working from that, I literally give up and don't continue trying. If it can't do anything useful like "place a simple component on the schematic" after ~10 USD of expenditure, is it really worth continue adding more money into the platform? Seems DOA in those cases.
I literally did this yesterday with solid results using Codex CLI. I used xhigh thinking and gpt 5.5.
I had it use KiCad directly via cli rather than via MCP, and I did make Claude Opus review it's work after every round. I got what I think will be a working revision A in about 10 hours of tinkering spread over a few days.
Would some sort of constraint-solving algorithm help with that? Something like (but not necessarily) Cassowary[0]? Maybe I'm misunderstanding what is meant by placement though; I don't have much domain knowledge in PCBs / electronics.
It does a pretty decent job on small hobby-project boards of ~40 components (which is my use case at the moment), and I'm working part-time in the background on scaling it further.
The resulting designs pass all the KiCad electrical and geometry checks. Granted, I've spent about a year working on this problem, and it's hard, but not that hard a problem, providing you can avoid falling off the exponential cliff by decomposing it into hierarchical subproblems.
Quick-and-dirty unsupervised whole-board synthesis from schematic takes about 5 minutes, longer if you want cleaner output with nicer-looking better-routed traces.
As others here have said, placing is the real problem to solve, and that's where the magic happens. Place the components right, and routing is a relatively easy loosely-coupled constraint programming problem, place them wrongly, and you will have to get used to seeing the word UNFEASIBLE in your log output.
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 the WDT and reset the CPU over and over again.
If you aren't there designing the thing in the first place, you never read the datasheets, never drew the schematic, never placed the components and thus don't know where to look when something goes wrong. And it does go wrong. And then you're in deep shit.
I worry about people who think they can get a product out of the door with this stuff but can't.
If you can’t or don’t entirely go over the output, the failure mode is invisible.
I can't find in archive.org if they had a previous post about it.
Also, seems like there a good bunch of complains in Reddit about Flux and its billing...
https://old.reddit.com/r/PCB/comments/1t476x4/warning_fluxai...
Nor is this Flux the display warmth app
Thank you, lawyers. If you ever find yourself out of work use this as your reference to pivot to advertisement
limor and i are very much looking forward to telling our story.
That if people were to email press@adafruit.com with a subject line (for example) of 'FLUX - AMA for later', these questions could be rounded up and the responses could then go onto a Adafruit blog page later, when and if applicable?
Does anyone have some more context about what happened here? An uncharitable analogy might be that I misconfigured my front door by not locking it, which doesn't give someone the right to walk in and look around - but I have no idea what Adafruit is specifically being accused of doing.
(I agree that Adafruit's statement itself is worded pretty terribly!)
When you discover an exploit, only communicate with source (and pray they respond) or get sued. Seems like the position is customers and stakeholders shouldn't be allowed access to this information.
https://www.cpomagazine.com/cyber-security/microsoft-doubles...
Seems especially useful when paired with an agentic coding tool!
Not only did it burn a 100$ failing but it did so in a very untransparent way.
I bought a 20 dollar plan but they snuck a 100$ billed usage into the billing agreements next thing I know the agent as used the quote going in circles and my card is billed.
I don't want to pay for a service that doesn't deliver.
A handful of honest participants like DeepSeek are pay as you go instead of trying to sneakily bill you for usage.
Not sure what the issue between them and Adafruit is. However, people over on Reddit¹ claim that Flux.ai is a little bit scummy. They push users into a beginner trial ($5/month) and then silently charge for usage per token - up to $100 per month.
Oh, they also claim that they have "the world's largest community-driven public library of Adafruit products, including footprints, symbols, datasheets, and simulation models"². I wonder whether they designed these themselves or whether they use existing ones. Could not easily find licenses info.
¹) https://www.reddit.com/r/PCB/comments/18o5zfo/thoughts_on_fl...
1. Make a slop machine that's a wrapper around another slop machine like claude, openai, google or whatever.
2. Hire a lawyer to send threatening emails to anyone that might call you out.
3. Get a few investors that are completely clueless to throw a ton of cash at you for having ai in your product.
4. Profit.
Honestly, get a hold of Louis Rossmann, this shit needs to stop.
The right use of AI would be to use it to create a better routing/synthesis tool, but that's not what is being worked on
10 x 0.1 = 1If you have a .6 chance of success on any particular outcome. Long term win or loss is down to your behaviour. If you double or nothing every time loss is guaranteed. The right strategy will win over the long term.
Same with most people "doing a startup" or "opening a restaurant". There will be arguments all day long about how these affairs are technically possible and quite lucrative if everything goes according to plan. But the reality is that vanishly few people are equipped to identify and stick to the right plan. Reality meeting theory.
I've told my developers they can use agentic coding if they want, but they must never mention it in the course of development. Not because I don't want to know, but because it's not going to change my evaluation of "their" work. If they can use the AI and get to a point that they can submit a PR that they themselves understand, then technically speaking, what do I care? But if it breaks the build or does something stupid and they don't understand it, it's going to be a bad day for them, whether they wrote it themselves or copied it out of StackOverflow or had Gemini do it.
Nobody has taken me up on this offer, because I think they know that they aren't going to have the extreme discipline to do the hard thing of understanding "someone" else's code and sign their name to it.
This is where my employer has ended up after extremely cautious AI adoption: _must_ be reviewed by a human, and the human whose name is on the gerrit review is responsible for the quality of the work.
For some reason the OpenAI dashboard shows me how much money the company as a whole has spent? It's still a very reasonable-looking amount of money and a tiny fraction of salaries.
I agree that people will rationalise being in a losing situation as a winning situation. That does not change the fact that winning situations can exist.
They probably aren't making a loss on the $3.10 Manhatten either.
https://www.casino.org/news/vegas-myths-re-busted-the-end-of...
Developers have to gamble on whether they will be better with AI or without.
The no excuses criteria means if they choose AI and it performs well, you both win, if it performs poorly they lose.
If they don't choose AI but colleagues do and it performs well, they lose relative to their colleagues.
The sensible solution would be solidarity and all reject the offer. Don't play the house.
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.
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 wanted to hurl my laptop out to the window.
I guess that works if you aren't a programmer or don't want to hire somebody, but then wtf would I pay for your service or product?
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?
Traditional methods might not be perfect, but they also easily fit in the memory of even low power devices. Perhaps it isn't a problem worth burning a dollar of tokens for every spelling mistake.
Don't do a stupid thing like that in the first place.
> In comparison to non-AI traditional tools, AI has the advantage of "understanding" the text, reducing the number of "stupid" mis-corrections.
I doubt it, but if that's true, run a normal spell checker, and then give the output to your LLM to filter.
> what is there to gain by interfacing it with traditional solutions,
About a billionfold improvement in compute efficiency, and a lower error rate.
> and how can it be achieved?
10 seconds of actual thought.
I think the bitter lesson is severely misapplied in the current situation: If progress from "just add more resources" is very slow, and a huge amount of money is at stake, continous work on hand-engineering can give a continuous and very valuable competitive advantage.
The labs all seem to be going for AGI through bigger LLMs, and I am reasonably sure that it's not going to happen like that.
I don't know if this is still the case. Labs like anthropic and openai are spending a huge amount of their time on custom model wrappers. Something which they used to leave to their customers is now core to their own business.
Plenty of people do, but that only produces a blog post that will get you to the front page of HN. If you want VCs to drop $40M on your head, you need to pretend to reinvent the world.
Then, to further appease the rain gods, you need to sue the bloggers on the front page of HN who are challenging your world-changing narrative. Which will, heh, drop you on the front page of HN.
Our community is, literally, eating itself at this point. There was a time when we actually took "make something people want" literally. Now it's just part of the fiction.
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 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.
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.