--dangerously-skip-reading-code • Hacker News Board

Re: --dangerously-skip-reading-code

#101

Post by ignoreusernames » Sat, May 23, 2026, 10:58 PM UTC

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…

Don’t you think that the provider of the LLM is also a dimension on these discussions about responsibility? We often talk about the tech itself (LLM driven development) but how we access it is just as important imo. It’s either locked behind a non trivial amount of hardware (for open models) or some monopolistic driven provider entity like OpenAI or anthropic. In the provider case, it’s not really the LLM that will “own” the code, it’s the provider itself and we’ll be at the mercy of whatever pricing model they shove down our throats.

Re: --dangerously-skip-reading-code

#102

Post by ricardobeat » Sat, May 23, 2026, 11:03 PM UTC

> We can’t leverage agents if our unit of work is still “add a new endpoint to the RESTful API”

Why not? You just make every task faster. Not everything has to be an uncontrollable rocket launch.

> We need a virtually infinite supply of requirements, engineers acting as pseudo-product designers, owning entire streams of work

Why? To build what? You can only build as fast as you understand the business and your users.

Re: --dangerously-skip-reading-code

#103

Post by [deleted] » Sat, May 23, 2026, 11:08 PM UTC

soraminazuki wrote: post #24

wizzwizz4 wrote: post #21

Earlier quoted context omitted.

You're probably thinking of Rice's theorem (a sort of generalised halting problem), but this task is actually way easier than that, since we're not trying to study arbitrary algorithms: we're trying to study the subset of human-comprehensible algorithms. Most of the things we want computers to do are things that, given enough time, someone can write a program to solve: and generally, those programs are not tricksy or…

We can't create an algorithm determining whether a computer program halts or not, but we can write one that checks whether it conforms to natural language specifications much more easily? That makes no sense. There's no exception to the halting problem regarding "human comprehensible" computer programs.

[deleted]

Re: --dangerously-skip-reading-code

#104

Post by invalidator » Sat, May 23, 2026, 11:21 PM UTC

culi wrote: post #85

humbleharbinger wrote: post #81

My amazon orgs leadership has been obsessed with spec driven development while individual engineers tell me the only use they have is to placate leadership. I'm tired

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 starts before implementation, and formalizes intent and high-level design. LLMs eat it up. The humans can easily reinvent the worst parts of waterfall if they're not careful.

They're not mutually exclusive.

Re: --dangerously-skip-reading-code

#105

Post by LelouBil » Sat, May 23, 2026, 11:33 PM UTC

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…

I don't like the premise of the article, but I agree that if you accept the premise, the contents of the articles are a good way to do it.

Re: --dangerously-skip-reading-code

#106

Post by blacob » Sat, May 23, 2026, 11:36 PM UTC

> Then where does the rigor go? Similar to the Thoughtworks report, my first bet would be specifications (which is not the same as prompts) and tests (which is not the same as TDD).

This is what we're building for at Saldor (https://saldor.com). It's a hard problem, to get a team in the habit of writing good specs. Probably because it's a hard thing to do: thinking of the behavior of your program, especially at the edges. But I agree (biased) that this is probably the way forward for writing code in the near future. I'm excited to see other people thinking about it.

Re: --dangerously-skip-reading-code

#107

Post by Uptrenda » Sat, May 23, 2026, 11:40 PM UTC

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…

[flagged]

Re: --dangerously-skip-reading-code

#108

Post by devmor » Sat, May 23, 2026, 11:44 PM UTC

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…

> Being a manager of software developers has always been a non-deterministic form of software engineering.

Unless the manager is also a principal/architect, I don’t find this to be agreeable.

It’s similar to saying that you are a non-deterministic chef when you order food from a restaurant.

Re: --dangerously-skip-reading-code

#109

Post by teaearlgraycold » Sun, May 24, 2026, 12:14 AM UTC

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…

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

Re: --dangerously-skip-reading-code

#110

Post by fractaled » Sun, May 24, 2026, 12:30 AM UTC

ninalanyon wrote: post #18

> Rework is almost free Is it? All the electricity and capital investment in computing hardware costs real money. Is this properly reflected in the fees that AI companies charge or is venture capital propping each one up in the hope that they will kill off the competition before they run out of (usually other people's) money?

Even ignoring the AI costs, 'rework' is going to be more expensive as soon as you have customers. For example any sort of data migration. Or UX expectations. Or public API interface. None of these can change without some thought, so one would be leaning on these specs quite a lot.