I like to say AI is like the super soldier serum from the MCU. Teams take it and either become Captain America or Red Skull, it depends on what you were to begin with.
I wish. The "captain Americas" are more like Tony Stark's jury rigged suit used in the desert (for now). It's not the suit truly doing innovation, it's the man inside who knows the suit (and its many limitations/flaws) inside out. Using the strengths long enough to escape before the hunk of metal inevitably fell apart.
The fact that it’s called “the quick pitch” screams Claude-written pithyness pulled from some context that doesn’t match the article’s style (like investment pitch decks).
As a tech educator I 100% agree. LLMs are not going to become a "new compiler" where we don't have to worry about the code any more. There's a reason we trust deterministic systems.
I've been worried about this a lot, I even created an agent skill called do-i-understand that's designed for novice devs (and experienced too, because atrophy) where the LLM asks you questions about the PR you're about to submit. I've found it helps a lot: https://github.com/AnthonyPAlicea/skills/blob/main/skills/do...
One way or another, there will be a skill reckoning.
It doesn't matter if the LLM is not deterministic.. the OUTPUT of typed code is deterministic in the sense that it can be seen to be type safe, compiled, and run appropriate unit tests on it.
If I use two LLM's to create some chunk of code and they both do it slightly differently but they both compile and pass appropriate tests.. it honestly doesn't matter if the LLM itself is not deterministic in exactly what it's going to output.
I would also argue- doesn't that make sense? You give two human coders the same task and they are also going to come up with slightly different results.
We don't run our own unit tests on compiled code because it generally can be trusted. LLMs are an extraordinarily leaky abstraction.
Saying "as long as it works and tests pass" suggests that we can test for every possible scenario. We can't. And tests can be flawed on top of it. Which is why an LLM is no more a compiler than a human coder (as you say) is.
It absolutely might make mistakes. But the skill requires all questions to be based on lines of code with specific line numbers which the human needs to review. That's intentional to serve as a safeguard against hallucinations.
they probably mean deterministic in the sense of traditional computer programs consisting of if-else decision points and ordinary cpu logic, as opposed to numerical models (which can of course be deterministic too, as you pointed out)
There are 2 levels of determinism that matter here IMO. Level 1, given the same input you get the same output. Level 2, you know what to change on the input to get a specific change on the output.
LLMs are currently capable of level 1, but not capable of level 2. Trust follows what is actually deterministic.
Trust should, but instead is being gulled by those incapable LLMs. And I don't see that changing, given the typical human's seemingly unlimited vulnerability to this con.
Then I think I'd rephrase you: There's a reason we trust trusted systems.
:)
Even their fans agree, LLMs are inherently unreliable. The fact some people trust them regardless is due to a deep flaw in human psychology that I believe has not been significantly exploited by any previous tech. There will be tears.
I’ve done a lot of work with the Office file formats over the years, flipping to .zip and messing with the format manually. Lately, because I’ve made courses with 500+ PowerPoint slides with lots of morph transitions, I iterated to find an approach that generally worked with Claude but is never perfect (using the Claude for PowerPoint plugin).
I switched to https://bento.page/ when it showed up here on HN and that’s been much more accurate I think because HTML and CSS is even more represented in training data.
Google switching to hallucinating AI summaries has been to me an absolutely shocking abdication of care for both their users and their own reputation.
It extends beyond search as well. I have had multiple incorrect Gmail summaries that, if I had only read them instead of the actual email, would have resulted in financial harm.
> Buttons regularly perform navigations. Clicking a logout button navigates the current page to a logged-out one; clicking a “search” button navigates the current page to the query results.
This seems to conflate appearance with semantics. If an element causes a navigation, I make it a link. Whether it looks like a button is irrelevant, that’s CSS.
I always choose one or the other by intended behavior first, and that always works out great.
> This seems to conflate appearance with semantics. If an element causes a navigation, I make it a link.
Neither of my examples work with links. Logout buttons must be buttons because they trigger unsafe requests, and "search" buttons are buttons because they submit the form as a query parameter. Both of these examples, are, however, navigations.[0]
> Whether it looks like a button is irrelevant, that’s CSS.
It's not irrelevant, because even if you style a link like a button (or vice versa), it will still behave like the thing it actually is. That's why it's important to have native HTML behavior that lets people use the right semantic element.
Presentation in what medium? A screen reader? You’re talking the user-agent stylesheet, which is a particular chosen presentation that I can change with my own CSS. I can make a button look like a link.
You’re suggesting aligning to an inherently and deliberately changeable presentation.
The idea is fine, but worry about what an HTML element “looks like” is not a good reason.
Imagining you have a navigation to “/logout” that server side invalidates your token and redirects to home, would you implement that as a link? If so, what happens if someone tries to “open in a new tab” it?
For me the spark is reinvigorated. I can try ideas before I didn’t have the time for, prototype and test and only pursue what proves to be worth the time.