Live data from Hacker News

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

matthewrocklin.com

211–220 of 241 posts

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

#211

Earlier quoted context omitted.

>> A compiler offers absolute guarantees I think one of the sibling comments addresses this myth rather neatly: https://news.ycombinator.com/item?id=46563383 tl;dr compilers are not fully deterministic either.

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 makes LLM output unverifiable. I said the latter is not true because you can perform verification using tests. You claimed tests are not verification because LLMs don't preserve the semantics.

I'm not sure why semantics matter. LLMs providing no guarantees regarding the preservation of semantics is not important because you can guarantee the behavior of the generated code using tests. In most domains, this is sufficient. You tell the LLM to write code that does X, Y and Z, and then verify X, Y and Z using a test. That's it.

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

#212

I clicked out of the article since it starts out with a contradiction. Experienced engineers can successfully vibe code? By definition it means not reading the output. If you’re not reading your output, then why does skill level even matter?

The definition of 'vibe code' is somewhat nebulous at the moment. For many it means "only look at the end product (website) and use prompts to fix it" but for others it means "mostly don't hand-code anything, but check the diffs".

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

#213
post #178

Earlier quoted context omitted.

If LLMs were like compilers, you could put src/ into .gitignore and only upload the prompt. Even the earliest compilers didn't work by the programmer writing code, copying the assembly output into their source tree, and throwing away the code. This is not a value judgement, they simply aren't the same thing at all.

here you go, a prompt only library: https://github.com/dbreunig/whenwords

That's great. Here's "me" implementing a JS version of that library in one shot using Github Copilot and a 1 sentence prompt:

> Implement when.js as a simple, zero-dependency js library following SPEC.md exactly.

https://github.com/jncraton/whenwords/pulls

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

#214
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

I've been a software engineer professionally for over two decades and I use AI heavily both for personal projects and at work.

At work the projects are huge (200+ large projects in various languages, C#, TypeScript front-end libs, Python, Redis, AWS, Azure, SQL, all sorts of things).

AI can go into huge codebases perfectly fine and get a root cause + fix in minutes - you just need to know how to use it properly.

Personally I do "recon" before I send it off into the field by creating a markdown document explaining the issue, the files involved, and any "gotchas" it may encounter.

It's exactly the same as I would do with another senior software engineer. They need that information to figure out what is going on.

And with that? They will hand you back a markdown document with a Root Cause Analysis, identify potential fixes, and explain why.

It works amazingly well if you work with it as a peer.

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

#215
post #203
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…

[deleted]

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

#216
post #146

> My personal favorite hooks though are these: "Stop": [ { "hooks": [ { "type": "command", "command": "afplay -v 0.40 /System/Library/Sounds/Morse.aiff" }]}], "Notification": [ { "hooks": [ { "type": "command", "command": "afplay -v 0.35 /System/Library/Sounds/Ping.aiff" }]}] These are nice but it's even nicer when Claude is talking when it needs your attention Easy to implement -> can talk to ElevenLabs or OpenAI an…

If you're on a Mac, it can speak the notification instead for more detail!

``` "hooks": { "Notification": [ { "hooks": [ { "type": "command", "command": "jq '.message' | say" } ] } ] } ```

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

#217
post #195

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…

No true Scotsman would ever do the kind of programming that 95% of the programming in the world is right? Anyway https://www.reddit.com/r/osdev/comments/1opsicd/just_how_far...

There's a good thread in there highlighting the fact that a novice wouldn't be nearly as successful as the OP who has the experience to guide the LLM.

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

#218

I suspect that lots of developers who are sour on relying on AI significantly _would_ agree with most of this, but see the result of that logic leading to (as the article notes) "the skill of writing and reading code is obsolete, and it's our job to make software engineering increasingly entirely automated" and really don't like that outcome so they try to find a way to reject it. "The skillset you've spend decades d…

> The parts of it that aren't high level product management and systems architecture are quickly becoming irrelevant

Embedded in this, is the assumption that many SWEs can actually do those roles better than existing specialists.

If they can't - end of the line

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

#219

Earlier quoted context omitted.

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…

One thing I have been doing is breaking out of my long-held default mode of spinning up a react/nextjs project whenever I need frontend, and generating barebones HTML/CSS/JS for basic web apps. A lot of the reason we went with the former was the easy access to packages and easy-to-understand state management, but now that a lot of the functionality packages used to provide can be just as easily generated, I can get a…

We used higher level programming languages because "Developer time is more expensive than compute time", but if the AI techbros are right, we are approaching the point where that is not going to be true.

It's going to take the same amount of time creating a program in C as it does in Python.

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

#220

Earlier quoted context omitted.

>Are so much people in programming implementing middleware / wrapping existing API all day that it gives them a feeling of liberation to be able to delegate those tasks ? Yes. A lot of jobs are providing the glue between other pieces like this and not inventing new algorithms and such. Perhaps this is why there is such a divide in sincere opinions about AI.

Which does indicate that even if AI becomes good at coding, we will still need humans to glue all the AI stuff together.

yeah, I don't think the jenga tower is changing but the levels of abstraction will.
Post reply on HN