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

-​-dangerously-skip-reading-code

olano.dev

Post reply on HN
Print view View original

211–219 of 219 posts

Re: -​-dangerously-skip-reading-code

#211

Post by rspeele »

insanitybit wrote: post #209
rspeele wrote: post #122

Earlier quoted context omitted.

Suppose the image resize service has some caching, and due to a bug in the caching, under certain circumstances it will respond with an already-cached resized version of a different source image. Let's say for example it caches on something stupid like the CRC32 of the input image -- good enough that the couple dozen images in your test dataset don't collide, you don't see it in smoke testing your app, but real world…

I found this sort of odd. What is your point? Is it good or bad that another team was responsible in one scenario?

Two points.

1. You can treat software like a black box when other people developed it for you because they can stand behind it. They have their own reputations to uphold. You can't when AI developed it for you because YOU are responsible for 100% of the bugs in it. If you take this trendy stance of "I never read or write code, just specs", you are just rolling the dice on what you stamp your name on.

2. Just because you have unit tests and you've tested the software by clicking through the app doesn't mean you've found every bug. There have always been bug types, like the example checksum collision, that are easier to detect by reading the code than by running the code because it will work most of the time even though the approach is wrong.

Re: -​-dangerously-skip-reading-code

#212

Post by insanitybit »

rspeele wrote: post #211
insanitybit wrote: post #209

Earlier quoted context omitted.

I found this sort of odd. What is your point? Is it good or bad that another team was responsible in one scenario?

Two points. 1. You can treat software like a black box when other people developed it for you because they can stand behind it. They have their own reputations to uphold. You can't when AI developed it for you because YOU are responsible for 100% of the bugs in it. If you take this trendy stance of "I never read or write code, just specs", you are just rolling the dice on what you stamp your name on. 2. Just because…

But I'm already responsible for the bugs in my software. Also, who cares if someone else is responsible? And how does that align with OSS's "no warranty provided"?

> There have always been bug types, like the example checksum collision, that are easier to detect by reading the code than by running the code

AI seems radically, insanely more qualified to not write bugs like that. I doubt that if you polled developers 99% would be able to tell you what a CRC32 even is, let alone why it's insufficient as a cache key.

Re: -​-dangerously-skip-reading-code

#213

Post by moritzwarhier »

culi wrote: post #121
urbandw311er wrote: post #97

Earlier quoted context omitted.

This is sometimes exposed in front end browser code and I had an actual (non technical) end user email our support team last month asking if it was something they should be concerned about! God knows how they found it, I suspect everyone is now an AI-enabled expert at these things…

Oh I've stumbled upon it myself while coding. You can ctrl/cmd-click into any React type and it will take you to its explicit source definition. I'm not sure if it's still the case but they used to have all of the types organized into a single file. Since I was the go-to TypeScript person at one job I had I made sure to familiarize myself with every type (less than you'd expect)

The point of that scary flag name was the stance that source maps should never be deployed in production.

There are stances that say they should, browse a large SPA with complex working source maps enabled, DevTools open, cache disabled and a long session (relevant because of HMR in dev), and you can see why this matters.

Browsers only fetch and process source maps in a development environment in production, that's why this flag name exists.

That being said, I still have a hobby project with an (in my opinion) sensible (at the time) Webpack configuration, and glossed over this being in the minified bundle, after 1-2 days at the time.

But if my hobby project would have been something production-relevant, I'd have continued to hunt down this artifact.

I think, with Vite et al this should not appear anymore in current JS bundles ready for prod, so the name is apt.

But the underlying problem is still a neverending source of frustration: minification is (by definition, when it's statically verifiable), not equipped to change object property names without provoking breakage.

Re: -​-dangerously-skip-reading-code

#214

Post by rspeele »

insanitybit wrote: post #212
rspeele wrote: post #211

Earlier quoted context omitted.

Two points. 1. You can treat software like a black box when other people developed it for you because they can stand behind it. They have their own reputations to uphold. You can't when AI developed it for you because YOU are responsible for 100% of the bugs in it. If you take this trendy stance of "I never read or write code, just specs", you are just rolling the dice on what you stamp your name on. 2. Just because…

But I'm already responsible for the bugs in my software. Also, who cares if someone else is responsible? And how does that align with OSS's "no warranty provided"? > There have always been bug types, like the example checksum collision, that are easier to detect by reading the code than by running the code AI seems radically, insanely more qualified to not write bugs like that. I doubt that if you polled developers 9…

> But I'm already responsible for the bugs in my software. Also, who cares if someone else is responsible? And how does that align with OSS's "no warranty provided"?

The original example from Simon Willison referred not to pulling in a 3rd party library, but working "at larger organizations" where "another team hands over something". In other words we area all working on the same product for the same company, they have been assigned another part of it and I'm expected to use their code.

In that scenario of course I care that someone else is responsible! It may affect whether I get fired or not!

It's different if you're a solo founder of a startup and for everything you ship, the buck stops with you. But proportionally many many more devs are in a situation where they are a cog in a machine.

> AI seems radically, insanely more qualified to not write bugs like that. I doubt that if you polled developers 99% would be able to tell you what a CRC32 even is, let alone why it's insufficient as a cache key.

I actually do agree that AI generally writes pretty good code. Doesn't mean I'm not gonna check. Sometimes it is too clever for its own good, such as re-implementing from scratch something that already exists and is well-proven.

The whole example is kind of contrived in the first place (how many environments don't have an excellent "image resizing" solution to reach for off the shelf?), so I hope you don't mind my bug example is also contrived.

Re: -​-dangerously-skip-reading-code

#215

Post by refactor_master »

LtWorf wrote: post #155
refactor_master wrote: post #138

Earlier quoted context omitted.

> Don't forget that very very detailed spec is actually the code The tests, sure. But certainly not the code itself, as that sits far too close to the implementation (i.e. it is the implementation). An almost infinite number of implantations can fulfill “does foo when bar”, so how can we prove that ours is the spec itself? It’s kind of like a scientist coming up with a hypothesis post-hoc to fit the results of the ex…

It'd be insane to come up with theories before doing any sort of observation.

In the realm of statistics, not so. If you're right on the limit of detectability, robust experimental design is necessary to avoid assigning meaning to noise.

Re: -​-dangerously-skip-reading-code

#216

Post by camgunz »

insanitybit wrote: post #210
camgunz wrote: post #176

Earlier quoted context omitted.

No, because those direct reports can use tools to build deterministic software. LLMs can't, because they themselves are non-deterministic. They will say they did, and they will be wrong. And the LLM you have check will also say it did, and it will be wrong. Etc etc. These things just can't be in the critical path. They are ridiculously unreliable.

What? Software being deterministic is not a feature of who wrote it. And how the hell is a human "deterministic"?

At the bottom of each of these arguments is a "who is accountable" question. You can tell an LLM "hey, use Lean to verify this" or "hey, do a code review" or "hey, write some tests and run them". It might do these things, it might not. You can then tell another LLM "hey, check that LLM A did these things". It might do these things, it might not. Repeat.

You can tell a human (an IC) the same things. You can then tell another human (a manager) "hey, check that IC A did these things". So far, these are the same. But there's now a critical difference: you can then hold those people accountable if they don't. They can be in the critical path. LLMs can't. People can improve. LLMs can't. People can work together. LLMs can't.

This doesn't always matter. You don't need things like accountability or improvement or teamwork all the time. But you do in reliable software.

Re: -​-dangerously-skip-reading-code

#217

Post by culi »

moritzwarhier wrote: post #213
culi wrote: post #121

Earlier quoted context omitted.

Oh I've stumbled upon it myself while coding. You can ctrl/cmd-click into any React type and it will take you to its explicit source definition. I'm not sure if it's still the case but they used to have all of the types organized into a single file. Since I was the go-to TypeScript person at one job I had I made sure to familiarize myself with every type (less than you'd expect)

The point of that scary flag name was the stance that source maps should never be deployed in production. There are stances that say they should, browse a large SPA with complex working source maps enabled, DevTools open, cache disabled and a long session (relevant because of HMR in dev), and you can see why this matters. Browsers only fetch and process source maps in a development environment in production, that's w…

I don't think it ever appeared in JS bundles. I'm just saying it's available to any dev in their IDEs with a simple ctrl+click

Re: -​-dangerously-skip-reading-code

#218

Post by lesscode »

crnkofe wrote: post #68
lesscode wrote: post #34

Instead of accepting 20,000 lines of slop per PR (and never-ending combinatorial complexity), maybe we should aim to think about abstractions and how to steer LLMs to generate code similar to that of a skilled human developer. Then it could actually be a maintainable artifact by humans and LLMs alike.

I don't get why every AI article is so hyper-focused on coding speed. If the coding is so fast doesn't it make sense to invest more time into quality, learning, documentation, testing refactoring, making a better product? I'm beginning to think that the slopcoders are evaluated by kLOCs of lines written in addition to LLM token usage and they're just maximising the measured metrics. Whether that actually ends up in p…

Indeed. If the goal is to make useful (quality) software artifacts, we are going in the wrong direction.

Re: -​-dangerously-skip-reading-code

#219

Post by moritzwarhier »

culi wrote: post #217
moritzwarhier wrote: post #213

Earlier quoted context omitted.

The point of that scary flag name was the stance that source maps should never be deployed in production. There are stances that say they should, browse a large SPA with complex working source maps enabled, DevTools open, cache disabled and a long session (relevant because of HMR in dev), and you can see why this matters. Browsers only fetch and process source maps in a development environment in production, that's w…

I don't think it ever appeared in JS bundles. I'm just saying it's available to any dev in their IDEs with a simple ctrl+click

In Webpack times, early React 18 days, manual config, "ejected" and adjusted from CRA, I did have it in my production bundle.

I just gave up checking on why after a couple hours because it was a hobby project.

Haven't seen it in a long time since then, but there are many overlapping factors here.

As far as I know, Vite/Rollup tree shaking is strictly better than what Webpack + Terser did, but I'm wondering where the difference comes from.

Maybe it's even a JSDoc annotation or something else that is esoteric.

Because tree-shaking all property names in JS without making static analysis arbitrarily complex, is still not possible.

So, if the change was not on React's side, I'd guess it is in bundler minifying heuristics or a backwards-compatible change that makes the property name inaccessible and erasable by other means.

Post reply on HN