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

21–30 of 219 posts

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

#21

Post by wizzwizz4 »

InsideOutSanta wrote: post #11
wizzwizz4 wrote: post #2

> There would need to be automated pull-request checks verifying not only that tests pass but that code conforms to the spec. As I understand, this is an unsolved problem.

Step 1: solve the halting problem.

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 meta, and don't involve unsolved mathematics problems found by studying busy-beaver candidates. If it's possible for a human to understand how a program works (which is a necessary component of writing such a program), it's possible to write a mathematical proof about the program's behaviour, and that means it's in principle possible to automate the construction of that mathematical proof, which is equivalent to the "determine whether code conforms to the spec" task.

"Somewhat easier than an impossible task" is not a particularly strong claim about when (or whether) this problem will be solved, though.

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

#22

Post by lefra »

Ecys wrote: post #5
wizzwizz4 wrote: post #2

> There would need to be automated pull-request checks verifying not only that tests pass but that code conforms to the spec. As I understand, this is an unsolved problem.

this is actually precisely what humans' roles will be. "is this implementation/code actually aligned with what i want to do?" humanic responsibility's focus will move entirely from implementing code to deciding whether it should be implemented or not. u probably mean unsolved as in "not yet able to be automated", and that's true. if pull-request checks verifying that tests are conforming to the spec are automated, th…

That's what formal verification is about. I did some (using PSL for hardware verification); writing the formal spec is way harder than the actual code. It will find a lot of subtle issues, and you spend a most of the time deciding if it's the spec or the code that's wrong.

Having the code-writing part automated would have a negligible impact on the total project time.

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

#23

Post by moritzwarhier »

Entertaining flag name!

React team seems to really have set a precedent with their "dangerouslySetInnerHTML" idea.

Or did they borrow it somewhere?

I'm just curious about that etymology, of course the idea is not universally helpful: for example, for dd CLI parameters, it would only make a mess.

But when there's a flag/option that really requires you to be vigilant and undesired the input and output and all edge cases, calling it "dangerous" is quite a feat!

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

#24

Post by soraminazuki »

wizzwizz4 wrote: post #21
InsideOutSanta wrote: post #11

Earlier quoted context omitted.

Step 1: solve the halting problem.

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.

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

#25

Post by dpark »

tyleo wrote: post #8

The underlying mechanism is still the same: humans type and products come out. So something which must be true if this author is right is that whatever the new language is—the thing people are typing into markdown—must be able to express the same rigor in less words than existing source code. Otherwise the result is just legacy coding in a new programming language.

> must be able to express the same rigor in less words than existing source code

Yes but also no. Writing source means rigorously specifying the implementation itself in deep detail. Most of the time, the implementation does not need to be specified with this sort of rigor. Instead the observable behavior needs to be specified rigorously.

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

#26

Post by hombre_fatal »

Yeah, this has been my process for months now.

I might even start my own blog to write about things I've found.

1. Always get the agent to create a plan file (spec). Whatever prompt you were going to yolo into the agent, do it in Plan Mode first so it creates a plan file.

2. Get agents to iterate on the plan file until it's complete and thorough. You want some sort of "/review-plan " skill. You extend it over time so that the review output is better and better. For example, every finding should come with a recommended fix.

3. Once the plan is final, have an agent implement it.

4. Check the plan in with the impl commit.

The plan is the unit of work really since it encodes intent. Impl derives from it, and bugs then become a desync from intent or intent that was omitted. It's a nicer plane to work at.

From this extends more things: PRs should be plan files, not code. Impl is trivial. The hard part is the plan. The old way of deriving intent from code sucked. Why even PR code when we haven't agreed on a plan/intent?

This process also makes me think about how code implementation is just a more specific specification about what the computer should do. A plan is a higher level specification. A one-line prompt into an LLM is the highest level specification. It's kinda weird to think about.

Finally, this is why I don't have to read code anymore. Over time, my human review of the code unearthed fewer and fewer issues and corrections to the point where it felt unnecessary. I only read code these days so I can impose my preferences on it and get a feel for the system, but one day you realize that you can accumulate your preferences (like, use TDD and sum types) in your static prompt/instructions. And you're back to watching this thing write amazing code, often better than what you would have written unless you have maximum time + attention + energy + focus no matter how uninteresting the task, which you don't.

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

#27

Post by tyleo »

dpark wrote: post #25
tyleo wrote: post #8

The underlying mechanism is still the same: humans type and products come out. So something which must be true if this author is right is that whatever the new language is—the thing people are typing into markdown—must be able to express the same rigor in less words than existing source code. Otherwise the result is just legacy coding in a new programming language.

> must be able to express the same rigor in less words than existing source code Yes but also no. Writing source means rigorously specifying the implementation itself in deep detail. Most of the time, the implementation does not need to be specified with this sort of rigor. Instead the observable behavior needs to be specified rigorously.

That doesn't sound right. For example, there's plenty of software with the correct observable behavior which leaks credentials. So what needs to be captured goes beyond observable behavior.

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

#28

Post by mjd »

soraminazuki wrote: post #20
InsideOutSanta wrote: post #11

Earlier quoted context omitted.

Step 1: solve the halting problem.

Yep, calling it an "unsolved" problem is a misnomer. We already have mathematical proof that it's impossible. But that aside, it's such a shame that many drinking the AI Kool-Aid aren't even aware of the theoretical limits of a computer's capabilities.

This sort of theoretical result is not always as clear-cut as you suggest.

Computers are finite machines. There is a theorem that although a machine with finite memory can add, multiplication requires unbounded memory. Somehow we muddle along and use computers for multiplication anyway.

More to your point there is a whole field of people who write useful programs using languages in which every program must be accompanied by a proof that it halts on all inputs.

(See for example https://lean-lang.org/ or David Turner's work on Total Functional Programming from about 20 years ago.)

Other examples are easy to find. The simplex algorithm for linear optimization requires exponential time in general, and the problem it solves is NP-hard, but in practice works well on problems of interest and is widely used. Or consider the dynamic programming algorithms for problems like subset-sum.

Theory is important, but engineering is also important.

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

#29

Post by jmull »

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

This is massive, a huge change, one which upends numerous assumptions about the business of software development.

...and it only leaves us to work through every other aspect of software development.

The approach this article advocates is to essentially pretend none of this exists. Simple, but will rarely produce anything of value.

This paragraph from the post gives you the gist of it:

> ...we need to remove humans-in-the-loop, reduce coordination, friction, bureaucracy, and gate-keeping. We need a virtually infinite supply of requirements, engineers acting as pseudo-product designers, owning entire streams of work, with the purview to make autonomous decisions. Rework is almost free so we shouldn’t make an effort to prevent incorrect work from happening.

As if the only reason we ever had POs or designers or business teams, or built consensus between multiple people, or communicated with others, or reviewed designs and code, or tested software, was because it took individual engineers too long to bang out decent code.

AI has just gotten people completely lost. Or I guess just made it apparent they were lost the whole time?

Post reply on HN