Live data from Hacker News

Write-only code

heavybit.com

31–40 of 59 posts

Re: Write-only code

#31

> The role of the human engineer […] has been to reduce risk in the face of ambiguity, constraints, and change. That responsibility not only endures in a world of Write-Only Code, if anything it expands. > The next generation of software engineering excellence will be defined not by how well we review the code we ship, but by how well we design systems that remain correct, resilient, and accountable even when no huma…

Would I use a write-only HTML sanitizer for untrusted HTML: No!

Would I care to review CSS, if my site "looks" good? No!

The challenge becomes: how can we enforce invariants/abstractions etc without inspecting the code.

Type systems, model checking, static analysis. Could become new power tools.

But sound design probably still goes far.

Re: Write-only code

#32

I am old. This immediately triggered "Perl!?" in me... Joke aside: Programming languages and compilers are still being optimized until the assembly and execution match certain expectations. So prompts and whatever inputs to AI also will be optimized until some expectations are met. This includes looking at their output, obviously. So I think this is an overblown extrapolation like many we see these days.

Ha! I had someone doing a task the other day and the llm they used wrote a regex in Perl. I joked that in 25 years all the seems to have changed is the number of layers between me and Perl.

Re: Write-only code

#33

He is trying to use a different phrase “write-only code” to define exactly the same thing Karpathy defined last year as “vibe coding”. For what it is worth, in my experience one of the most important skills one should strive to get much better at to be good at using coding agents is reading and understanding code.

> good at using coding agents is reading and understanding code.

You can understand the code using an agent; it's much faster than reading the code.

I think the argument the author is making is that: given this magic oracle that make code, how we so contain and control it.

This is about abstractions and invariants and those will remain important.

Re: Write-only code

#34
I helped updating ancient fortran to slightly less ancient C once. The company that depended on the ancient fortran no longer had any fortran programmers.

The resulting software upgrade was a nightmare that nearly killed that company. I shudder if someone needs to fix 20 year old AI write only code and I feel for the poor AI that has to do it. Because an AI 'intelligent' enough to do that deserves holidays and labor rights.

Re: Write-only code

#37
> Write-Only Code is not a prediction about what we should want. It is a description of what happens when software production scales beyond human attention.

Have we considered whether it's even a good idea to produce software at scales beyond human attention? I'm beginning to suspect that, in terms of the net amount of economic effort and sheer quantity of software produced, we are already creating simply too much software relative to the amount of economic effort we put into hardware, construction, and human capital. Most human needs and desires can only be met through manipulation of atoms, and it seems as though we've largely refocused on those which can be met through manipulation of numbers and symbols - not because anyone really wants their life to revolve around them to the exclusion of everything else - but because they're the easiest markets to profitably scale for the least amount of capital input.

Re: Write-only code

#38
We already have effectively write-only code. It's all the assembly language and eventually machine code that we produce from other languages.

The problem with "write-only code" as it relates to LLMs is that we don't have a formal definition of the input the the LLM, nor do people typically save the requirements, both implicit and explicit, that were given the LLM to generate the code. English language will never be a formal definition, of course, but that obviously doesn't prevent the creation of a formal definition from English nor reduce the value of the informal description.

This is very similar to the problem of documentation in software development. It is difficult to enumerate all the requirements, remember all the edge cases, recall why a certain thing was done in a certain way. So computer programs are almost never well documented.

If you knew that you currently have a bunch of junior developers, and next year you will replace all of them with senior developers who could rewrite everything the junior developers did, but taking only a day, how would that affect your strategy documenting the development work and customer/technical requirements? Because that's what you have with current LLMs and coding agents. They are currently the worst that they'll ever be.

So there are two compelling strategies:

1) business as usual, i.e. not documenting things rigorously, and planning to hack in whatever new features or bugfixes you need until that becomes unsustainable and you reboot the project.

2) trying to use the LLM to produce as much and as thorough documentation and tests as possible, such that you have a basis to rewrite the project from scratch. This won't be a cheap operation at first, (you will usually do strategy #1), but eventually the LLMs and the tooling around managing them will improve such that a large rewrite or rearchitecture costs <$10k and a weekend of passive time.

Re: Write-only code

#39

I helped updating ancient fortran to slightly less ancient C once. The company that depended on the ancient fortran no longer had any fortran programmers. The resulting software upgrade was a nightmare that nearly killed that company. I shudder if someone needs to fix 20 year old AI write only code and I feel for the poor AI that has to do it. Because an AI 'intelligent' enough to do that deserves holidays and labor…

Do you mind sharing how exactly it turned out to be a disaster? What went wrong?

Re: Write-only code

#40
post #38

We already have effectively write-only code. It's all the assembly language and eventually machine code that we produce from other languages. The problem with "write-only code" as it relates to LLMs is that we don't have a formal definition of the input the the LLM, nor do people typically save the requirements, both implicit and explicit, that were given the LLM to generate the code. English language will never be a…

Is that really true though? Are people really not saving design documentation to the code repository along with the code? And is it really too much to ask in a prompt to make the LLM document aggressively? Do the LLMs you use complain about being asked to write lots of comments in their code? Is it a token cost thing? It seems ridiculous not to just start with #2 but I might be spoiled by not knowing how much my token usage costs.
Post reply on HN