Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My article on why AI is great (or terrible) or how to use it

matthewrocklin.com

Post reply on HN
Print view View original

231–240 of 241 posts

Re: My article on why AI is great (or terrible) or how to use it

#231

Post by Leynos »

emseetech wrote: post #15
CharlesW wrote: post #5

I get vibe-coders not having a good experience once the honeymoon is over. But I'm fascinated that a professional software developer could have such a different experience than I do. • LLMs generate junk • LLMs generate a lot of junk

My question is why use AI to output javascript or python? Why not output everything in C and ASM for 500x performance? Why use high level languages meant to be easier for humans? Why not go right to the metal? If anyone's ever tried this, it's clear why: AI is terrible at C and ASM. But that cuts into what AI is at its core: It's not actual programming, it's mechanical reproduction. Which means its incapabilities in…

I pretty much do most of my AI coding in Rust. Although I do still use Python or Typescript where appropriate.

Re: My article on why AI is great (or terrible) or how to use it

#232

Post by [deleted] »

AdieuToLogic wrote: post #162
nl wrote: post #152

Earlier quoted context omitted.

> Compilers are deterministic, making their generated assembly code verifiable People keep saying this like it is an absolute fact, whereas in reality it is a scale. Compilers are more deterministic than LLMs in general, but no they are not completely deterministic. That's why making reproducible builds is hard! https://stackoverflow.com/questions/52974259/what-are-some-e... and https://github.com/mgrang/non-determin…

>> Compilers are deterministic, making their generated assembly code verifiable > People keep saying this like it is an absolute fact, whereas in reality it is a scale. My statement is of course a generalization due to its terseness and focuses on the expectation of repeatable results given constant input, excluding pathological definitions of nondeterminism such as compiler-defined macro values or implementation def…

[deleted]

Re: My article on why AI is great (or terrible) or how to use it

#233

Post by BeetleB »

Verdex wrote: post #99
BeetleB wrote: post #91

Earlier quoted context omitted.

We, as SW engineers, have been doing that to many industries for the last 40+ years. It's silly and selfish to draw the line now that we're in the crosshairs.

I've spent my 20 year career working largely in medical software. The only jobs I've been replacing are pancreas that stop functioning correctly. Maybe don't speak for all of us.

My comment wasn't about you in particular but the industry as a whole.

Much of the software written historically is to automate stuff people used to do manually.

I'd wager you use email, editors, search engines, navigation tools and much more. All of these involved replacing real jobs that existed. When was the last time you consulted a city map?

Re: My article on why AI is great (or terrible) or how to use it

#234

Post by lunar_mycroft »

aspenmartin wrote: post #92
lunar_mycroft wrote: post #83

Earlier quoted context omitted.

> It's like the articles point: we don't do assembly anymore and no one considers gcc to be controversial and no one today says "if you think gcc is fun I will never understand you, real programming is assembly, that's the fun part" The compiler reliably and deterministically produces code that does exactly what you specified in the source code. In most cases, the code it produces is also as fast/faster than hand wri…

That a coding agent or LLM is a different technology than a compiler and that the delta in industry standard workflow looks different isn’t quite my point though: things change. Norms change. That’s the real crux of my argument. > But for hyping up the technology well beyond it's actual merits, antagonizing people who point out it's shortcomings, and subjecting the rest of us to worse code? Yeah, I hold that against…

As others has already been pointed out, not all new technologies that are proposed are improvements. You say you understand this, but the clear subtext of the analogy to compilers is that LLM driven development are a obvious improvement and if we don't adopt them we'll find ourselves in the same position as assembly programmers who refused to learn compiled languages.

> Is that what I’m doing?

Initially I'd have been reluctant to say yes, but this very comment is laced with assertions that we'd better all start adopting LLMs for coding or we're going to get left behind [0]

> taking the gcc analogy, in the early compiler days there was a period where compilers were weak enough that assembly by hand was reasonable. Now it would be just highly inefficient and underperformant to do that

No matter how good LLMs get at translating english into programs, they will still be limited by the fact that their input (natural language) isn't a programming language. This doesn't mean it can't get way better, but it's always going to have some of the same downsides of collaborating with another programmer.

[0] This is another red flag I would hope programmers would have learned to recognize. Good technology doesn't need to try to threaten people into adopting it.

Re: My article on why AI is great (or terrible) or how to use it

#235

Post by vrighter »

enraged_camel wrote: post #211
vrighter wrote: post #164

Earlier quoted context omitted.

please point out where i said "deterministic". I said guarantees that semantics are preserved.

I don't know what you are arguing, or why. Please follow the thread in its full context. Specifically, the argument the article author is making is that moving to a higher level of abstraction also cost developers the benefit of understanding the internals. Ultimately, that ended up not mattering very much. The OP pushed back on this, saying compilers are deterministic and LLMs are not, and that lack of determinism m…

no, writing tests to verify that the "compiled" code semantically matches the code in the source language is not a good thing. The guarantees that I'm talking about are different.

You write tests for your own logic, not to do the compiler's job.

I have no idea why you are so stuck on determinism. That has nothing to do with what i'm saying. Sure compilers can be nondeterministic with things such as register allocation, but that is totally transparent to the programmer. The compiled code will do exactly what the source code describes. The nondeterminism in llms does not apply just to those things. An llm's nondeterminism might mean it decides to encode different logic, instead of a different implementation that is logically equivalent.

We don't usually write steps to verify that the compiler decided to ignore our code and do its own thing. You have to do that with llms

Re: My article on why AI is great (or terrible) or how to use it

#236

Post by enraged_camel »

vrighter wrote: post #235
enraged_camel wrote: post #211

Earlier quoted context omitted.

I don't know what you are arguing, or why. Please follow the thread in its full context. Specifically, the argument the article author is making is that moving to a higher level of abstraction also cost developers the benefit of understanding the internals. Ultimately, that ended up not mattering very much. The OP pushed back on this, saying compilers are deterministic and LLMs are not, and that lack of determinism m…

no, writing tests to verify that the "compiled" code semantically matches the code in the source language is not a good thing. The guarantees that I'm talking about are different. You write tests for your own logic, not to do the compiler's job. I have no idea why you are so stuck on determinism. That has nothing to do with what i'm saying. Sure compilers can be nondeterministic with things such as register allocatio…

Nobody suggested using LLMs as a compiler.

Re: My article on why AI is great (or terrible) or how to use it

#237

Post by lunar_mycroft »

simonw wrote: post #203
sph wrote: post #191

Earlier quoted context omitted.

I don't get this. AI coders keep saying they review all the code they push, and your suggestion is to use even harder languages the average vibe coder is unable to understand, all in name of "performance"? Faster code maybe, and exponentially increasing the tech debt and amount of bugs that slips through. It wasn't even long ago that we thought developer experience and capacity for abstraction (which is easier to ach…

> AI coders keep saying they review all the code they push Those tides have shifted over the past 6 weeks. I'm increasingly seeing serious, experienced engineers who are using AI to write code and are not reviewing every line of code that they push, because they've developed a level of trust in the output of Opus 4.5 that line-by-line reviews no longer feel necessary. (I'm hesitant to admit it but I'm starting to joi…

In the past week, I saw Opus 4.5 (being used by someone else) implement "JWT based authentication" by appending the key, to a (fake) header and body. When asked to fix this, it switched to hashing the key (and nothing else), and appending the hash instead. The "signature" still did not depend on the body, meaning any attacker could trivially forge an arbitrary body, allowing them to e.g. impersonate any user they wanted to.

Do I think Opus 4.5 would always make that mistake? No. But it does indicate that the output of even SotA models needs careful review if the code actually matters.

Re: My article on why AI is great (or terrible) or how to use it

#238

Post by bdauvergne »

jascha_eng wrote: post #200
bdauvergne wrote: post #189

Seems people read the blog but not the code, I looked at the stated rewrite of Numpy in Rust: > As an introductory project, I rewrote Numpy in Rust. It was great fun. That's not a rewrite at all it's just a wrapping of an existing linear algebra Rust library (faer, blas, etc..) with a more Numpy like API. It seems to me that every AI project I look at is just a mashup/wrapper over existing things. Where are the real…

https://github.com/timescale/pg_textsearch BM25 index for postgres, mostly written by a single (very smart) guy and Claude Code.

Written by a nobody of course:

> T.J. Green is a Senior Staff Engineer at Tiger Data, creators of TimescaleDB, where he is the implementor of pg_textsearch, a new Postgres extension for high-performance BM25 ranked text search. He brings deep expertise in database systems internals and indexing methods to this project. At Tiger Data, he has also contributed to pgvectorscale, the company's vector search extension for Postgres.

The guy could have written it eyes closed.

Re: My article on why AI is great (or terrible) or how to use it

#239

Post by aspenmartin »

lunar_mycroft wrote: post #234
aspenmartin wrote: post #92

Earlier quoted context omitted.

That a coding agent or LLM is a different technology than a compiler and that the delta in industry standard workflow looks different isn’t quite my point though: things change. Norms change. That’s the real crux of my argument. > But for hyping up the technology well beyond it's actual merits, antagonizing people who point out it's shortcomings, and subjecting the rest of us to worse code? Yeah, I hold that against…

As others has already been pointed out, not all new technologies that are proposed are improvements. You say you understand this, but the clear subtext of the analogy to compilers is that LLM driven development are a obvious improvement and if we don't adopt them we'll find ourselves in the same position as assembly programmers who refused to learn compiled languages. > Is that what I’m doing? Initially I'd have been…

My intention was to say: you won't get left behind you will just get left slightly behind the curve until things reach a point where you feel you have no choice but to join the dark side. Like gcc/assembly: sure maybe there were some hardcore assembly holdouts but any day they could and probably did jump on the bandwagon. This is also speculation, I agree, but my point is: not using LLMs/coding agents today is very very reasonable, and the limitations that people often bring up are also very reasonable and believable.

> No matter how good LLMs get at translating english into programs, they will still be limited by the fact that their input (natural language) isn't a programming language.

Right but engineers routinely convert natural language + business context into formal programs, arguably an enormously important part of creating a software product. What's any different here? Like a programmer, the creation process is two-way. The agent iteratively retrieves additional information, asks questions, checks their approach, etc etc.

> [0] This is another red flag I would hope programmers would have learned to recognize. Good technology doesn't need to try to threaten people into adopting it.

I think I was either not clear or you misread my comment: you're not going to get left behind any more than you want to. Jump in when you feel good about where the technology is and use it where you feel it should be used. Again: if you don't see value in your own personal situation with coding agents, that is objectively a reasonable stance to hold today.

Re: My article on why AI is great (or terrible) or how to use it

#240

Post by jascha_eng »

bdauvergne wrote: post #238
jascha_eng wrote: post #200

Earlier quoted context omitted.

https://github.com/timescale/pg_textsearch BM25 index for postgres, mostly written by a single (very smart) guy and Claude Code.

Written by a nobody of course: > T.J. Green is a Senior Staff Engineer at Tiger Data, creators of TimescaleDB, where he is the implementor of pg_textsearch, a new Postgres extension for high-performance BM25 ranked text search. He brings deep expertise in database systems internals and indexing methods to this project. At Tiger Data, he has also contributed to pgvectorscale, the company's vector search extension for…

Yes TJ is very experienced and smart. But no he would not have been able to build this in a few months by himself without AI. In fact he uses Claude so much that he goes over the max subscription and spends thousands of dollars each month on tokens to continue delivering this fast.

AI is a big multiplier for experienced folks like him.

Post reply on HN