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

91–100 of 219 posts

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

#91

Post by abalashov »

retinaros wrote: post #56

markdown became the language I hate the most thank to LLMs and specs-driven approach. everything feels so dumb right now in agentic coding. looping blindlessly and aimlessly until it compiles then until the playwright server or whatever devtools shows that it somehow works. push the code, have a llm autoreview/autofix,push to prod, run a mythos (perfect name) to identify the bug that opus 4.7 create. loops on loops o…

A colleague and I have taken to use of the verb "meatspin", from another era in Internet shock humour, to describe what it is that coding agents actually do 99% of the time.

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

#92

Post by nullsex »

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?

[dead]

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

#94

Post by dpark »

tyleo wrote: post #80
dpark wrote: post #72

Earlier quoted context omitted.

Leaking credentials is observable behavior. Certainly you could write specification for a piece of software, and the software could meet the specification while also leaking credentials. Obviously, that would be a problem. But at some point, this starts to feel artificial and silly. The same software could reformat your hard disk, right? At some point, we aren’t discussing whether or not AI is doing a bad job writing…

If leaking credentials is observable behavior. I don't get your point. Memory leaks, deleting the hard drive, spending money would all be observable behavior. By your reasoning that the "observable behavior needs to be specified rigorously" it seems like you'd have to list these all out. We do, after all, already have cases of AI deleting data. That sounds harder and more error prone than what we're doing now by rigo…

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, only if it meets my retirements.

The move to AI first software development will not happen because we find a way to specify as much in English as we previously would have specified in a programming language. The move will happen when and as we figure out how to specify the things that matter. We don’t need the same rigor. We need the correct rigor.

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

#95

Post by facundo_olano »

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 while still preserving the rigor somewhere else?

This was a follow up to a previous article[1] and the pair tried to express what I still think today (using AI daily at work): every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed. This is not necessarily always a bad tradeoff, but I think it's important to constantly remind ourselves we are making it.

[1] https://olano.dev/blog/tactical-tornado/

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

#96

Post by kortex »

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 specs feels like a slog.

Also at times aspects of the english language spec end up way more verbose than just giving a code example would be.

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

#97

Post by urbandw311er »

culi wrote: post #89
brabel wrote: post #69

Earlier quoted context omitted.

I think people used similar prefixes for a long time. For example, Haskell has had `unsafePerformIO` since the 90's... and MSFT's Hungarian notation was also similar, though it used abbreviations for things like "unsafe" (not "dangerous"). Perhaps React was the most famous case of using "dangerously" though.

"unsafe" seems quite different from the "dangerously [...]" phrasal template. I don't think it's a stretch to suppose it was inspired by React. Still waiting for this one to catch on: React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED https://github.com/reactjs/react.dev/issues/3896

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…

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

#98

Post by pyrale »

IsTom wrote: post #67
20k wrote: post #38

Earlier quoted context omitted.

What we really we need is some kind of more detailed spec language that doesn't have edge cases, where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement. It'd be super helpful to have something more formal with no ambiguity, especially because the english language tends to be pretty ambiguous in general which can result…

> What we really we need is some kind of more detailed spec language that doesn't have edge cases, where we describe exactly what we expect the generated code to do, and then formally verify that the now generated code matches the input spec requirement. That's theorem provers and they're awful for anything of any reasonable complexity.

That's any programming language, really [1]. Any website contains millions of "proofs", not all of them are useful. Choosing what needs to be proven is hard. And the spectrum of languages/type systems and their usability as either is more explored nowadays than it used to be. If you don't likue coq, you can look for agda. If agda is too far for you, you can look for Haskell. If that's still impractical, there's rust or f#, etc... The tradeoff you have between "convenient for expressing proofs" and "convenient for programming" has many options.

[1]: https://www.youtube.com/watch?v=IOiZatlZtGU

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

#99

Post by iloveoof »

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 non-deterministic outputs much faster than team leads/managers can review, understand or approve every diff. Being a manager of software developers has always been a non-deterministic form of software engineering.

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

#100

Post by SpicyLemonZest »

giancarlostoro wrote: post #86
SpicyLemonZest wrote: post #76

Earlier quoted context omitted.

Is Claude good at working with XML prompts, or is XML good at convincing users to write more Claude-able specs? I am intensely skeptical that you could write an XML document describing a nontrivial web application in full detail, but I could easily imagine someone who thinks they have to stripping out important details because they don't really map to XML.

They train it with XML even the system prompts that Claude reads are formatted by it.

I haven't done it professionally, but my understanding is that this kind of work is much more in the second category, where you have to understand the closest approximation to what you want that the LLM can reliably produce or the training won't work at all.
Post reply on HN