d0liver

If, by your definition of understanding, you can understand something without knowing how it works, then what would be the point in understanding it?

Your argument underscores the fact that understanding exists on a spectrum and that deep understanding can be difficult, or even impossible to achieve. Even formal verification seeks to verify certain properties of a system, and doesn't represent anything close to comprehensive understanding, and the process of formal verification is also guided by a fallible human. In a lot of ways, formal verification is just pushing up to review of a different "programming language."

So, good review is really hard, but ignoring the difficulty doesn't make it go away.

What if I told you that understanding what it is doing and finding bugs is actually the same problem?

I think you just made some strong arguments for classifying them as gatekeepers. The idea, like you said, is to make it so that competitors can enter the market and pick up the slack in areas where AWS and Azure are dropping the ball.

In other words, for the primary uses of search things have gotten much worse, but some workarounds still exist.

software was already in a horrible state before AI, so your dichotomy doesn't work.

It depends on the software. But, generally speaking, I try to use and write the best software available that solves my problem, even if it's one of a kind; it doesn't really matter if the other 99.9999% of the software in the space is broken.

Given 1000 hours to work on a problem, an LLM will continue to yeet out mediocre variations on a theme. Give me 1000 hours to work, and my product will keep getting 1% or 2% better until it's much better than any shit an LLM would spit out.

Similarly, I would much rather use someone else's emulator that they spent 1000 hours on than have AI yeet out some mediocre shit that kinda works, but is really just a mindless exploitation of something that someone else wrote that was actually good.

Then, you follow that with, "Yeah, but AI just allows you to iterate faster and skip the boring stuff, so that you make your product better even faster."

And then I follow that with, "The part where you take it apart piece by piece and study each piece and get kicked in the head by the realities of your lack of understanding is the part that's actually valuable, and it's precisely what you're skipping with an LLM"

I would much rather have software that works but lacks accessibility features than software that's broken but also has some broken accessibility features sprinkled in. The former is useful to many people, while the latter is useful to no one.

But the key here is: LLMs don't have latent rigor, nor any other kind of rigor.

What makes you say that AI is not going anywhere? I hear this overwhelmingly, "AI is here to stay", as if y'all are so caught up in the movement that you've started taking that conclusion as being the axiom. TBH, it feels like a religion.

Getting people into coding is both cool and also not specific to AI.

Gross .

This isn't a JS specific issue.

"If you travelled back in time, the coastline itself would be unrecognisable to modern eyes. In the Jurassic Period, most of what later became Britain was under the sea, apart from Scotland, East Anglia and a series of small islands in the southwest."

https://www.nhm.ac.uk/discover/life-in-jurassic-oceans.html

It's clear that the article is mostly talking about the reader's ability to interpret figuratively, regardless of the specific reference. However, I'm not even sure it's a biblical reference, because I think dinosaurs are generally incompatible with the story of Noah's Arc. I'm guessing it's probably more along the lines of some theory of continental movement that was prevalent at the time. Maybe it's just a weird mismash of dinosaurs and Noah's Arc, though?

if all the water left, it could be dry like a desert too

This is just a contextual interpretation thing. It's clear that's not what he means because he says it's muddy, so it must be the other thing. Also, it becoming a desert is more extreme, so in that case the writer would probably offer up a more detailed explanation.

Someone saying they vibe coded a thing is like them saying they were hammered when they wrote it. Maybe they did a great job, but probably not; it's definitely cause for concern.

Unnecessary access isn't a solveable problem. In order to restrict permissions to exactly what a program needs, in general, you'd have to define exactly what a program does. In other words, you'd need to rewrite the program with self-enforcing access restrictions.

So, permissions are always going to be more general than what a program actually needs and, therefore, exploitable.

Producing incorrect information is an insidious example of this. We can't simply restrict the program's permissions so that it only yields correct outputs -- we'd need to understand the outputs themselves to make that work. But, then, we're in a situation where we're basing our choices on potentially incorrect and unverified outputs from the program.

My impression was that it's next gen because it's using Rust on WASM as opposed to something that compiles to JavaScript.

However, I could be wrong. There's a small semantic difference between "next gen Rust web UI library" and "next gen web UI library written in Rust"

I think that's kind of the point though: AI is the sand, but it's the rocks that hold all of the value; the further you get away from using AI the more real value you obtain. Like, a few of the rocks have gold deposits in them, and the sand is just infinitely copious but never holds anything valuable. And you've got a bunch of people running around saying, "Behold my mountains of sand!"

IIRC, you can do git branch -D $(git branch) and git will refuse to delete your current branch. Kind of the lazy way. I never work off of master/main, and usually when I need to look at them I checkout the remote branches instead.

This issue exists with the parsed case, too. If you're using a database to store data, then the lifecycle of that data is in question as soon as it's used outside of a transaction.

We know that external systems provide certain guarantees, and we rely on them and reason about them, but we unfortunately cannot shove all of our reasoning into the type system.

Indeed, under the hood, everything _is_ just a big blob that gets passed around and referenced, and the compiler is also just a system that enforces preconditions about that data.

I think, more generally, "push effects to the edges" which includes validation effects like reporting errors or crashing the program. If you, hypothetically, kept all of your runtime data in a big blob, but validated its structure right when you created it, then you could pass around that blob as an opaque representation. You could then later deserialize that blob and use it and everything would still be fine -- you'd just be carrying around the validation as a precondition rather than explicitly creating another representation for it. You could even use phantom types to carry around some of the semantics of your preconditions.

Point being: I think the rule is slightly more general, although this explanation is probably more intuitive.

As I understood it the trick was effectively to dump the full public API documentation of one of those services into their agent harness and have it build an imitation of that API, as a self-contained Go binary. They could then have it build a simplified UI over the top to help complete the simulation.

This is still the same problem -- just pushed back a layer. Since the generated API is wrong, the QA outcomes will be wrong, too. Also, QAing things is an effective way to ensure that they work _after_ they've been reviewed by an engineer. A QA tester is not going to test for a vulnerability like a SQL injection unless they're guided by engineering judgement which comes from an understanding of the properties of the code under test.

The output is also essentially the definition of a derivative work, so it's probably not legally defensible (not that that's ever been a concern with LLMs).

Definition one on Merriam Webster is, "To make into a product suitable for use." This is what I thought you meant, because cost of production is what it costs to forego buying something. IMO, that's the cost you really want to consider.

If the tool is saving you a large chunk of time, then why does it matter what's happening in another industry? We seem to be losing a really simple thread here: Pay for things because they present more value to you than you're giving away in payment.

Y'all seem to have some notion of what constitutes "fair" payment that you're so attached to that you're willing to shoot yourselves in the foot.

I assumed that they meant "cost of production", since that's what you give to keep your money, so that includes 0->1. But if what they meant is what you said then I'd say that the cost of 0->1 is not somehow less important. Software does make 1->100 much more accessible though, so, in that way, you have an opportunity to help out very small businesses in a way that you can't in other industries, which is even more of a reason to buy code from your peers, IMO.

Manufacturing costs are zero

No. The fact that you built something yourself doesn't make it free to produce.

More over, you __won't__. You simply cannot build all of the things that you could buy at scale. What if you had to write all of your own video games? Or operating systems?

How do you know that it's actually faster than if you'd just written it yourself? I think the review and iteration part _is_ the work, and the fact that you started from something generated by an LLM doesn't actually speed things up. The research that I've seen also generally backs this idea up -- LLMs _feel_ very fast because code is being generated quickly, but they haven't actually done any of the work.

Yes, but then the study result should be, "AI correctly identifies 100% of breast cancers in study"

If we're saying there was a discrepancy and we're saying that all of the patients had cancer, then it would seem that there must have been some that were identified as not having cancer by AI.

there were zero false negatives

Wouldn't this mean that AI identitied them all has having cancer?

Hey, this looks cool. Out of curiosity, how did you create your initial listing of jobs? Did you scrape job data from elsewhere, or maybe you looked at other listings and built yours up by hand?

To save face and make it look like an iteration rather than a reversal.