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

181–190 of 219 posts

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

#181

Post by andrekandre »

ninalanyon wrote: post #48
vinnymac wrote: post #45

Earlier quoted context omitted.

I appreciate your insights in a sea of psychosis comments. I find it strange how many people think we have achieved the likes of Y2K flying cars 20 years ago, or the dream of having every car on the road be an electric fully self driving car by now (a promise made at least over a decade ago by several of these types). The point I’m making is that we give the spotlight to people who are making absurd claims. We have n…

And if we do remove the human from the loop? What then, what are humans for? Do we get Keynes' idea that we only need to work a few hours a week or do we get a continuation and intensification of what we already have: a few high 'earners' and a sea of people struggling to make ends meet?

  > What then, what are humans for?
why, to make money for the boss of course!

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

#182

Post by dpark »

skydhash wrote: post #173
dpark wrote: post #94

Earlier quoted context omitted.

My ultimate point is that source code specifies everything the software can or will do, but most of that is not part of the required specification. Most of it is implementation details you don’t care about. The entire reason we have functions and components and modules etc is to isolate engineers from the things we do not need to care about. I should not need to care about the implementation details of most software,…

> I should not need to care about the implementation details of most software, only if it meets my retirements. The only reason those details don’t matter to you is because someone has gone through the pain of ironing out every details that have not made it into the specifications. One one side you have the platform and on the other side you have the interface contract (requirements). Saying what’s in the middle does…

> The only reason those details don’t matter to you is because someone has gone through the pain of ironing out every details

I disagree. Very often the reason the details don’t matter is that they are irrelevant. There are a million ways an app might remember my personal settings, as a simple example. SQLlite db, json file, ini, cloud storage, registry, etc. The specific implementation matters very little so long as it’s sane.

> Saying what’s in the middle doesn’t matter is strange

I understand your point but do not agree. I think over the next decade we will get increasingly good at specifying rigorously the parts of the surface that matter while increasingly caring less and less about the rest. We will not find a way to write rigorous code in English because that would necessarily be less efficient than just using a programming language.

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

#183

Post by [deleted] »

evolve-maz wrote: post #84
jmull wrote: post #29

The lesson I've learned from our new AI age is how little a large number of people who've worked in software development their entire careers understand software development. I suppose all the money floating around AI helps dummify everything, as people glom on to narratives, regardless of merit, that might position them to partake. What we actually have now is the ability to bang out decent quality code really fast…

All the talking points and techniques are those which were used when pushing outsourcing: give better specs, write detailed tests, accept bad code because it works so who cares, we can just rewrite from scratch later, and my favorite "they will get better with more exposure to your code base". None of these takes is wrong, but what they neglect is doing all that work is way more effort than if I wrote the original co…

[deleted]

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

#184

Post by jonnytran »

kortex wrote: post #96
zoogeny wrote: post #61

>... my first bet would be specifications ... and tests ... If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. I've found that adopting RFC Keywords (e.g. RFC 2119 [1]; MUST, SHOULD, MAY) at least makes the LLM report satisfaction. I'd love to see a proper study on the usage of RFC keywords and their effect on compl…

That's literally what OpenSpec does ( https://openspec.dev/ ). It's quite nice. I've only exceptionally rarely seen claude do something wrong based on spec docs when it's fully spec'd out. More often it's because something wasn't nailed down and claude was forced to make assumptions. The downside is the ospx markdown specs sometimes end up too granular, focusing on the wrong or less important details, so reading the…

Is it time for the literate programming renaissance?

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

#185

Post by skydhash »

dpark wrote: post #182
skydhash wrote: post #173

Earlier quoted context omitted.

> I should not need to care about the implementation details of most software, only if it meets my retirements. The only reason those details don’t matter to you is because someone has gone through the pain of ironing out every details that have not made it into the specifications. One one side you have the platform and on the other side you have the interface contract (requirements). Saying what’s in the middle does…

> The only reason those details don’t matter to you is because someone has gone through the pain of ironing out every details I disagree. Very often the reason the details don’t matter is that they are irrelevant. There are a million ways an app might remember my personal settings, as a simple example. SQLlite db, json file, ini, cloud storage, registry, etc. The specific implementation matters very little so long as…

> There are a million ways an app might remember my personal settings, as a simple example. SQLlite db, json file, ini, cloud storage, registry, etc. The specific implementation matters very little so long as it’s sane.

It may not matter if you’re just an end user. But if you’re the one deciding the tools to be used, you may wonder about consistency (sqlite is better than a json file or ini file), availability (local storage is better than a cloud service), security risks,… Trusting an LLM to take care of that looks like negligence to me.

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

#186

Post by jeppester »

alabut wrote: post #113
iloveoof wrote: post #99

Software engineering has always worked this way, just not to ICs. “The LLMs produce non-deterministic output and generate code much faster than we can read it, so we can’t seriously expect to effectively review, understand, and approve every diff anymore. But that doesn’t necessarily mean we stop being rigorous, it could mean we should move rigor elsewhere.“ Direct reports, when delegated tasks by managers, product n…

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…

This leaves out the part where you ask the original developer: "Why does this thing do that?"

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

#187

Post by runarberg »

theshrike79 wrote: post #159
runarberg wrote: post #135

Earlier quoted context omitted.

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

Personally, if my company would have one person write a utility which mine would depend on, and that person would quit soon after delivery, I would be pissed. And I would demand that my team take ownership of the utility, and gain intimate knowledge of the utility, and voice my concerns with management who made the decision to hand out a task like that to a single person. I would then inform that management about the concept of bus factor, and how they just violated best practices. That next time they decide to hand out a task like that to a single person, that they should instead just hand it out to the team which is gonna rely on that utility.

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

#188

Post by dpark »

skydhash wrote: post #185
dpark wrote: post #182

Earlier quoted context omitted.

> The only reason those details don’t matter to you is because someone has gone through the pain of ironing out every details I disagree. Very often the reason the details don’t matter is that they are irrelevant. There are a million ways an app might remember my personal settings, as a simple example. SQLlite db, json file, ini, cloud storage, registry, etc. The specific implementation matters very little so long as…

> There are a million ways an app might remember my personal settings, as a simple example. SQLlite db, json file, ini, cloud storage, registry, etc. The specific implementation matters very little so long as it’s sane. It may not matter if you’re just an end user. But if you’re the one deciding the tools to be used, you may wonder about consistency (sqlite is better than a json file or ini file), availability (local…

> Trusting an LLM to take care of that looks like negligence to me.

You are of course entitled to hold your opinion. How to work with LLMs successfully will be determined by those who believe it’s possible rather than those who argue it’s fundamentally negligent, though.

The arguments against AI coding have rapidly evolved from “it’s not possible” to “it’s possible but breaks down as soon as the system gets complex” to this “it works but it’s negligent” argument. The industry will continue to move on.

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

#189

Post by dapperdrake »

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…

It gets better:

(NOT a lawyer)

Previously, liability and indemnification could be bureaucratically laundered to "engineers", because it was a huge diffuse set of people.

Now the bag is left with top of the chain for authorizing LLMs. Gia Tan went the hard way with xz. LLM-trolling is the new social engineering.

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

#190

Post by culi »

invalidator wrote: post #104
culi wrote: post #85

Earlier quoted context omitted.

How does spec driven development differ from test driven development?

TDD is done in a tight loop (minutes) while coding. For every little micro-feature/fix, you write a test for the new behavior you want, implement the minimal ugly fix to get the test to pass, then rely on the tests so you don't regress as you clean up. LLMs struggle with TDD. They want to generate a bunch of code and tests in large passes. You can instruct them to do red/green TDD, but the results aren't great. SDD s…

In many frameworks the tests are referred to as the "spec". I guess that's where my confusion arises from.

> SDD starts before implementation

No different from TDD.

Post reply on HN