Comment by pjc50
4 hours ago
> 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.
1 reply →
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.
1 reply →
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.
I swear that so many AI usecases I see are: "I did not have the skill or realize that you can write a program for this obvious logic".
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?
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?
20 replies →
Way too much engineering effort to make something that might get leapfrogged by the next gen LLM.
It's a tantalizing thing, but far too treacherous to actually go for it, most of the time.
There are many domains where a hybrid of numeric and AI approaches would make sense. For example in those domains where there's already a rich practice of numeric tools such as with IC layout.
Something something bitter lesson blah blah
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.
> The labs all seem to be going for AGI through bigger LLMs
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.
A few days ago someone on HN commented that a teammate uses Claude to search for text in files on their own computer. Buddy... There's Command-line Tools Can Be 235x Faster Than Your Hadoop Cluster and then there's Command-line Tools Can Be ∞ Faster Than Your AI.
As snark, I've been using the phrase "ask GPT about it" for things that clearly do not need an LLM to be involved. The other day, I was on a zoom call and said it, only to see the present actually doing it. I hope my unmuted laugh wasn't too distracting.
> nobody [wants to use AI] to augment already working solutions
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.
That precise mixed technique approach has worked well for me. I’ve been using JITX (python based circuit design with a powerful auto router). Free for personal use, and has been discussed a few times here in HN.
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.
https://www.jitx.com/
Until a few years ago it was generally understood that useful "creativity" involves solving problems within constraints, e.g. something a lot like SAT or SMT in spirit even if not in the details.
Then we got LLMs which will make a good parody of anything and occasionally get it right.
Within an IC you don't have large obstructions for metal layers, distances are short, and buffers can be inserted at will to manage SI.
It has been about 20 years since I worked on this (clock gating and clock buffering), but ..
> distances are short
I remember we had a catastrophic error for "wire longer than 2cm".
> and buffers can be inserted at will to manage SI.
Effective buffering of large nets was a massive pain. Areas where you want to buffer are inevitably areas with a very high level of placement congestion. So you push some cells out of the way to add a buffer. That ends up worsening their timing. So they need a bit more sizing/buffering. Rinse and repeat for a few hours.
( https://web.archive.org/web/20071028033035/http://www.edn.co... ; long since absorbed into Cadence)
It is far from solved in IC, synthesis tools sometimes still do really stupid things and there's still quite a lot of hand-holding required to get to a working chip.
And LLM are even stupider and need even more hand-holding
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