Live data from Hacker News

Write-only code

heavybit.com

41–50 of 59 posts

Re: Write-only code

#41
post #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.

> Could become new power tools.

If this worked, it’d have worked on low cost devs already. We’ve had the ability to produce large amounts of cheap code (more than any dev can review) for a long time.

The root issue is it’s much faster to do something yourself if you can’t trust the author to do it right. Especially since you can use an LLM to speed up your understanding.

Re: Write-only code

#42
post #19

I’ve started doing a quick background check on authors before I dive into their content. This piece starts with the assumption that the writer is closely involved in engineering, but a little research reveals they don't actually work in active software development. I’ll pass on this. p.s. I’m happy to read authors with opposing views. Issue is with people who make claims, without having recent direct experience.

A better test is to see if the author stands to financially (or other ways) benefit from the posts future predictions coming true. They also fail this one.

Re: Write-only code

#43

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.

I am not old but started programming early. It also triggered "Perl??" and "PHP??".

Re: Write-only code

#44

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…

I imagine, only slightly extrapolating current AI trends, that in 20 years most codebases can be easily modified by AI. I'd even say they are especially well suited to such tasks that typically don't require extremely abstract and complex logic, or imagination, but rather "just" a huge attention span and a lot of work.

Re: Write-only code

#45
post #19

I’ve started doing a quick background check on authors before I dive into their content. This piece starts with the assumption that the writer is closely involved in engineering, but a little research reveals they don't actually work in active software development. I’ll pass on this. p.s. I’m happy to read authors with opposing views. Issue is with people who make claims, without having recent direct experience.

But you can be a software dev even if you do not work in software dev. Plenty of those individuals in open source, for example.

writing software for a hobby is different from hundreds of thousand that do it 40+ hours per week, go into planning into retros into milestone review meetings etc.

I am painting in my free time as a hobby. I do not think I am an authority or should be taken seriously when taking about impact of AI on artists.

Re: Write-only code

#46
post #42
post #19

I’ve started doing a quick background check on authors before I dive into their content. This piece starts with the assumption that the writer is closely involved in engineering, but a little research reveals they don't actually work in active software development. I’ll pass on this. p.s. I’m happy to read authors with opposing views. Issue is with people who make claims, without having recent direct experience.

A better test is to see if the author stands to financially (or other ways) benefit from the posts future predictions coming true. They also fail this one.

That is also an influence, although that has a risk if one over-indexes on it and getting into tunnel-vision territory.

If the opposing view is indeed correct and I dismiss them just because they voted with their feet or money, that would be unfair and damage building a diverse view of the debate landscape and opinions.

Re: Write-only code

#47

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…

I imagine, only slightly extrapolating current AI trends, that in 20 years most codebases can be easily modified by AI. I'd even say they are especially well suited to such tasks that typically don't require extremely abstract and complex logic, or imagination, but rather "just" a huge attention span and a lot of work.

Tricky bit with ancient codebases is that their only requirements, generally speaking, tend to be that they should keep working exactly like they have been since 1983, except for the bit that needs changing of course, that needs to change in a way that implements the change, but doesn't have any unintended side-effects in a system that is a fractal of undocumented interdependencies (systems that have been patched for a few decades under those types of constraints tend to become especially gnarly that way).

Re: Write-only code

#48
We tried adoption of Claude Code at my last job as our PM was quite excited about its potential and I saw some horrors that were raised during code review (where I thankfully read the code):

- Using private undocumented APIs subject to breaking changes;

- Removing a call to produce a message to an external topic, with no internal references besides tests, declaring it as "redundant" (it was very much not redundant);

- Repeated duplication of formatting, calculation, and permission logic, causing inconsistencies and bugs.

They met whatever goal the agent created for itself, but they would've broken several features in ways that would've been difficult to test for, either today or in the future.

Re: Write-only code

#49

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.

I think there's some value in pure vibe coding. To your point though, the best way to extract that value is to know intimately at which point the agents tend to break down in quality, which you can only do if you read a lot of their output. But once you reach that level, you can gain a lot by "one-shotting" tasks that you know are within their capacity, and isolating the result from the rest of your project.

How often do the AIs devolve at some task? Or does switching models make those assumptions inaccurate?

Re: Write-only code

#50
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 toke…

It requires real work to create good documentation and review it.

I've never worked in a place that requires that every commit update some documentation, but if you want to rebuild software based on the documentation, that's what it would take.

The best you could say is that the typical development process today tends to scatter documentation across commit descriptions, feature docs, design reviews, meeting notes, training materials, and source code comments.

To have a hands-off rewrite of a codebase with LLMS, you would need a level of documentation that allows a skilled human to do the rewrite without needing to talk to anyone else. I doubt that any project would have this unless it was required all along.

Post reply on HN