←back to thread

YC is wrong about LLMs for chip design

(www.zach.be)
317 points laserduck | 3 comments | 16 Nov 24 14:07 UTC | HN request time: 0.001s | source
Show context
fsndz ◴[16 Nov 24 17:05 UTC] No.42157451[source]▶
They want to throw LLMs at everything even if it does not make sense. Same is true for all the AI agent craze: https://medium.com/thoughts-on-machine-learning/langchains-s...
replies(10): >>42157567 #>>42157658 #>>42157733 #>>42157734 #>>42157763 #>>42157785 #>>42158142 #>>42158278 #>>42158342 #>>42158474 #
marcosdumay ◴[16 Nov 24 17:24 UTC] No.42157567[source]▶
If feels like the entire world has gone crazy.

Even the serious idea that the article thinks could work is throwing the unreliable LLMs at verification! If there's any place you can use something that doesn't work most of the time, I guess it's there.

replies(5): >>42157699 #>>42157841 #>>42157907 #>>42158151 #>>42158574 #
ajuc ◴[16 Nov 24 17:44 UTC] No.42157699[source]▶
It's similar in regular programming - LLMs are better at writing test code than actual code. Mostly because it's simpler (P vs NP etc), but I think also because it's less obvious when test code doesn't work.

Replace all asserts with expected ==expected and most people won't notice.

replies(4): >>42157802 #>>42157883 #>>42158103 #>>42158154 #
1. majormajor ◴[16 Nov 24 18:07 UTC] No.42157883[source]▶
LLMs are pretty damn useful for generating tests, getting rid of a lot of tedium, but yeah, it's the same as human-written tests: if you don't check that your test doesn't work when it shouldn't (not the same thing as just writing a second test for that case - both those tests need to fail if you intentionally screw with their separate fixtures), then you shouldn't have too much confidence in your test.
replies(1): >>42158133 #
2. marcosdumay ◴[16 Nov 24 18:33 UTC] No.42158133[source]▶
If LLMs can generate a test for you, it's because it's a test that you shouldn't need to write. They can't test what is really important, at all.

Some development stacks are extremely underpowered for code verification, so they do patch the design issue. Just like some stacks are underpowered for abstraction and need patching by code generation. Both of those solve an immediate problem, in a haphazard and error-prone way, by adding burden on maintenance and code evolution linearly to how much you use it.

And worse, if you rely too much on them they will lead your software architecture and make that burden superlinear.

replies(1): >>42158320 #
3. williamcotton ◴[16 Nov 24 18:54 UTC] No.42158320[source]▶
Claude wrote the harness and pretty much all of these tests, eg:

https://github.com/williamcotton/search-input-query/blob/mai...

It is a good test suite and it saved me quite a bit of typing!

In fact, Claude did most of the typing for the entire project:

https://github.com/williamcotton/search-input-query

BTW, I obviously didn't just type "make a lexer and multi-pass parser that returns multiple errors and then make a single-line instance of a Monaco editor with error reporting, type checking, syntax highlighting and tab completion".

I put it together piece-by-piece and with detailed architectural guidance.