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

151–160 of 219 posts

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

#151

Post by stuaxo »

jimmaswell wrote: post #123
facundo_olano wrote: post #95

Author here. I'm surprised to see this surfacing now. I just wanted to clarify, since apparently the post doesn't do a good job at it, that what I discussed there is not a methodology I advocate for. The point of the post was: ok, since there are organizations mandating to maximize speed by reducing time spent on typing code (or even mandating to maximize agents usage), is there a way we can meet that requirement whi…

> every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. Sure, but couldn't you say the same for letting other people contribute code too? In either case, you make the choice of how deeply you want to review it. You can ask the AI or the human to explain things that aren't clear. For me it's case by case in either scenario. Sometimes it's not…

The people can meaningfully collaborate and produce something of high quality.

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

#152

Post by stuaxo »

kenhwang wrote: post #132
jimmaswell wrote: post #123

Earlier quoted context omitted.

> every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. Sure, but couldn't you say the same for letting other people contribute code too? In either case, you make the choice of how deeply you want to review it. You can ask the AI or the human to explain things that aren't clear. For me it's case by case in either scenario. Sometimes it's not…

I always wondered why people don't also ask the AI to generate code comments/documentation, summaries of those documentation, overview of the system, and re-review them all for correctness for the changes they asked the AI to do. What I've noticed reviewing all my colleagues' AI generated code PRs is: it really is just code, and the rare comment here and there is still added by the human. We're already trying to ligh…

You get LLMs like Gemini that will assure you they are right.

There seems to be a big push for 0 reviewing, which is insane.

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

#153

Post by stuaxo »

refactor_master wrote: post #138
throwaw12 wrote: post #59

> my first bet would be specifications and tests You are missing another dimension how easy it would be to migrate if adding new feature hits a ceiling and LLM keeps breaking the system. Imagine all tests are passing and code is confirming the spec, but everything is denormalized because LLM thought this was a nice idea at the beginning since no one mentioned that requirement in the spec. After a while you want to ad…

> 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…

I've found LLM written unit tests to be fairly low quality which makes sense as writing good tests takes understanding that writing good code.

Also the quality of tests in general in projects is often so so and that's reflected in the output of LLMs even more so.

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

#154

Post by sokoloff »

khasan222 wrote: post #147
facundo_olano wrote: post #95

Author here. I'm surprised to see this surfacing now. I just wanted to clarify, since apparently the post doesn't do a good job at it, that what I discussed there is not a methodology I advocate for. The point of the post was: ok, since there are organizations mandating to maximize speed by reducing time spent on typing code (or even mandating to maximize agents usage), is there a way we can meet that requirement whi…

For sure every time you use ai you’re sacrificing understanding if you don’t plan out and understand how exactly the ai is going to do the work you asked it to do. The same output that is such a bad thing in this article can also be used to gain context, by making a thorough plan with your ai first, reading through the plan and proposing changes just like you would with a real developer. You can also use this output…

I think most people test at least a happy path of their code end to end. I think we can all agree that your last sentence is far more aspirational than bare minimum standard practice. (“I believe we should be spending our energy thoroughly manually testing a feature to make sure when we brainstormed we actually did get every edge case, and it works well.”)

I did one small side web project by only writing spec tests and prompts and testing the results in a browser, never reading nor editing a single line of generated code. It was something for home and so low stakes, but it worked remarkably well and was much better tested than the typical 2022-era home project of mine.

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

#155

Post by LtWorf »

refactor_master wrote: post #138
throwaw12 wrote: post #59

> my first bet would be specifications and tests You are missing another dimension how easy it would be to migrate if adding new feature hits a ceiling and LLM keeps breaking the system. Imagine all tests are passing and code is confirming the spec, but everything is denormalized because LLM thought this was a nice idea at the beginning since no one mentioned that requirement in the spec. After a while you want to ad…

> 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.

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

#156

Post by LtWorf »

npodbielski wrote: post #143
theshrike79 wrote: post #137

Earlier quoted context omitted.

> Don't forget that very very detailed spec is actually the code In the age of AI this is more true than you know. Given a detailed enough spec and test suite you can effectively rewrite any application with any language in a fully automated way. I've coined that as "Duck coding" :D If it quacks like a duck, walks like a duck and looks like a duck - it's duck enough for as far as the spec is concerned. Does it matter…

Yes. It would be like buying a car that you have no idea about the engine and gearbox and kind of fuel it is using or if at all. It have four wheels and and it can drive you from point A to B. Sure but sometimes it happens that some particular brands and they particular model requires engine renovation after 100k km because it is so shitty design. Right now we are just starting vibe coded software, nobody knows how i…

The problem is that you cannot just throw away your data.

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

#157

Post by ekidd »

Npovview wrote: post #140
teaearlgraycold wrote: post #109

Earlier quoted context omitted.

Well yes but if no humans at the company understand the code then no one is truly responsible for it.

what about the artifacts that were supposed to test the correctness of the code? are they passing willy nilly?

No amount of testing will save a large program with a dogshit architecture. Roughly, this is because tests increase coverage linearly with the number of tests, but weird interactions increase exponentially with code size.

This might be fine if you're building a tiny app, or if you're building a medium-sized app that follows a strict existing architecture (like a web app consisting mostly of forms). In which case, have fun.

But if you're building something slightly novel and interesting, then Claude is surprisingly bad at architecture and taste, and it tends to "fix" problems by spewing more slop. What you need instead is actual insight that leads to simplifying principles. This, in turn, allows breaking up the exponential complexity into disciplined patterns. This allows your code complexity to scale far more slowly, allowing an essentially linear number of tests to provide coverage.

I actually download and try people's vibe-coded developer tools. And frankly, those tools are some of the worst software I've used in my life, worse than even Unix-vendor Motif implementations from the early 90s.

Like, I'm super happy that people can vibe-code themselves simple, one-off personal tools. That's incredibly empowering. But that doesn't mean you can big, novel stuff the same way without a competent human actively in the loop.

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

#158

Post by ossopite »

kenhwang wrote: post #132
jimmaswell wrote: post #123

Earlier quoted context omitted.

> every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. Sure, but couldn't you say the same for letting other people contribute code too? In either case, you make the choice of how deeply you want to review it. You can ask the AI or the human to explain things that aren't clear. For me it's case by case in either scenario. Sometimes it's not…

I always wondered why people don't also ask the AI to generate code comments/documentation, summaries of those documentation, overview of the system, and re-review them all for correctness for the changes they asked the AI to do. What I've noticed reviewing all my colleagues' AI generated code PRs is: it really is just code, and the rare comment here and there is still added by the human. We're already trying to ligh…

The docs/summaries part I can get behind if reviewed and improved by a human, but at least when working in pre-existing codebases, I tend to steer models away from writing comments, because I find that almost all comments they write are "not even wrong".

That is: they either reiterate what the code does, or would if the code were slightly clearer, or they tell half truths that are more confusing than helpful. Mostly they fail to emphasise the salient things, like the why over the what, that are not obvious from the code.

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

#159

Post by theshrike79 »

runarberg wrote: post #135
alabut wrote: post #113

Earlier quoted context omitted.

Simon Willison made a similar parallel recently: https://simonwillison.net/2026/May/6/vibe-coding-and-agentic... “The thing that really helps me is thinking back to when I’ve worked at larger organizations where I’ve been an engineering manager. Other teams are building software that my team depends on. If another team hands over something and says, “hey, this is the image resize service, here’s how to use it to resi…

Simon Willison’s analogy does not apply unless that other team was immediately fired after they delivered the image resize service, or (more commonly) was done by a one off contractor. The difference is the trust model. We trust that our company has hired a competent team which maintains knowledge of the image resizing service, that they respond to bug reports and feature requests and that they know how to fix and im…

Why does the team need to be "fired"?

The single person who did the service might just quit and go to another job. They might be external consultants that rotate away when the contract ends. It might be a SaaS service where you don't control the code at all - nor the composition of their team.

We have trusted services, contractors and teams within our companies before. Now suddenly _everyone_ has ALWAYS read and meticulously analyzed every single line of code they have ever imported to a project?

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

#160

Post by theshrike79 »

ekidd wrote: post #157
Npovview wrote: post #140

Earlier quoted context omitted.

what about the artifacts that were supposed to test the correctness of the code? are they passing willy nilly?

No amount of testing will save a large program with a dogshit architecture. Roughly, this is because tests increase coverage linearly with the number of tests, but weird interactions increase exponentially with code size. This might be fine if you're building a tiny app, or if you're building a medium-sized app that follows a strict existing architecture (like a web app consisting mostly of forms). In which case, hav…

> those tools are some of the worst software I've used in my life

Is the code bad or don't they do what they claim they do? Both are very different issues.

Post reply on HN