frumiousirc

I think this characterization misses the feedback loop that exists.

The OP is not sitting in a one-way flow of info:

    LLM->human->code 

but rather a the center of a feedback loop:

    LLM<-->human<-->code.  

Human-is-the-loop, not human-in-the-loop. Each iteration of that loop is fully driven by the human. Human creativity is involved in both directions.

I'd argue that anytime we drive an LLM through more than one turn (and/or more than one session) we are really doing a human-is-the-loop thing. The OP's extreme case of begin the only thing editing code is on a spectrum with the other extreme being vibe coding (never looking at output code, but still interacting with that output in some way).

Off the spectrum is what I call LLM-vomit. A human one-shots something and puts it out for others to see, suffer and clean up or ignore. This is code that is encountered literally out of context and can only be further improved (if that is even attempted) by approaching it from first principles. Such code is akin to people using LLM to generate an answer delivered to another human. Both flavors (sorry) of LLM-vomit are bad. I can prompt my own LLM to do that, don't do it for me.

It could be useful more as a labor saving device to enable censoring while allowing the human to engage in easy copy-paste. Examples I think of are inclusion of internal DNS names, usernames and human names and email addresses that may be intermixed with log or command output needed to debug some issue.

That said, if these strings are really sensitive and I'm too lazy (or not trusting the human user) to self-censor, I'd not rely on this particular kind of tool for censoring. I'd use local LLMs or cloud LLMs where privacy is part of the contract.

A key feature about data-flow programming that seems too often missed is that it is (or can be) hierarchical.

Define a subgraph of atomic nodes as itself a node with its ports formed from as-yet unconnected ports of its atomic constituents. Compose yet higher subgraphs of subgraphs and atomic nodes. Package all this in some way.

This is directly analogous to syntactic programming where functions aggregate other function calls and all that packaged into a library with an API.

Perhaps bad/naive ideas, but consider these options for unlocking where the requirements changes after one incorrect entry.

- After an incorrect key, require two (or more) consecutive valid key entries.

- After an incorrect key, no longer accept that nominal key until a secondary key is supplied.

It seems Google already /dev/null's this search term.

    Your search - site:claude.ai/share - did not match any documents.

> I really wish Ruff would introduce something similar to Nix’s stateVersion

Two approaches:

You can pin the version of `ruff` in `pyproject.toml`.

You, to let ruff command version advance but pin the settings to a prior version:

    uvx ruff@0.15.22 check --isolated --show-settings | flat2toml > pinned.toml
    

The `flat2toml` script is left as an exercise. Then in `ruff.toml`:

    extend = "pinned.toml"

ruff is not new. It's also truly really fast. On an as-yet un-ruff'ed 32k SLOC python package it returns in 158ms finding 2k errors. Having it fix errors is also very fast.

What's really tiring is reading such facile "critiques", especially when they are not even applicable.

I'd be happy if things stopped interfering with standard X11 select/paste. It's now a random crap shoot if I have to hold Shift or not to regain that elegance.

And, the whole idea of copy/paste having to use both mouse AND keyboard (select Ctrl-c click Ctrl-v) is barbaric. X11 got it right and it seems all "modern" apps are trying really hard to introduce barbarisms.

> For Markdown to Org translation, Pandoc will be used.

Hmm, pandoc? Surely....

    M-x org-import-<TAB>

Damn, why does this family of functions not yet exist?

I don't know the full break down but some is going to university and DOE lab groups and some of those are even exploring interesting and useful ideas.

It's fitting a theme of self-deprecation if we consider the origin of the name "git", no?

I really want to see the point-of-view video of that tumble.

> The result is Project Tina

This is a small typo in the text. It's spelled "ZeroMQ".

True. Though, I self censor to appease myself as I have caught myself picking up claudisms. I was mortified when I realized that I had started to use "land" as a verb related to finishing some bit of work.

I think you are right.

The title of the figure is ambiguous about what "SD" really means but I guess it is plotting the number of standard deviations of the 1991-2020 data measured from the mean of that data and plotted per day for the 1982-2026 data.

Here's the link that I read off the figure.

https://climatereanalyzer.org/clim/sst_daily/json_2clim/oiss...

Going up the URL path I get redirected to here:

https://climatereanalyzer.org/clim/sst_daily/?dm_id=world2

That shows measured temperature and 2026 as very hot (surprise) and in fact is the hottest to date for June+July. The standard deviation of that data is not 3.5 C but something less than 1.0 C. It is plausible that current temperature is about 3.5 sigma from the selected mean.

It's worth recognizing that the analysis is applying a biased conclusion prior to making the plot. It singles out post 2020 data to compare to pre-2020 data. and then concluding the held out data is a significant deviation with a cause. It almost certainly is but this is not a proper way to analyze data (unless one is pushing an agenda, be that for good or bad).

I think the sst_daily plot stands on its own without crafting this SD plot to emphasize the point. Especially when the accompanying text doesn't even explain it. It's a disingenuous message.

I'm reminded of the contributions of Naomi Wu. https://archive.org/details/youtube-4VKZTmTP7oY

Another way to interpret it is that a massive sample bias is governing your premise. Programmers are embracing LLMs to scratch their own itches and programmers tend to work in terminals (yes, many use IDEs) so they build to their own environments and HN readers and contributors tend to be programmers talking about programming things.

I'd settle for Altman and his ilk paying a proper progressive income tax.

It's not so straight-forward. Either you must add hooks the the agent to notify tmux directly or you must use an external tool that polls tmux to determine one of its panes has gone silent and then based on that, send notification to tmux.

The poling requires tmux (not screen nor dtach, as far as I could find). And, silence for N seconds is just that, the poll doesn't know if that really means waiting for input or something else. With agents (like claude) that have a throbber/spinner going while "thinking", silence is a good indicator.

Kitty terminal can be polled for current text and then see if that has changed in N seconds. This would allow not having to depend on tmux which may be preferable to some kitty users. Generally, using tmux always surfaces some annoying problems for me.

This split in what different people or groups get out of LLMs is pervasive and really interesting. In the beginning I was dismissive of those with bad experience with a "you are holding the tool wrong" smugness. But as I read more and more experience, I see all combos and I now know my initial knee jerk conclusion was clearly wrong. There are newbie programmers getting good or bad results as well as experienced developers getting either flip of the coin. I don't know what to conclude. I really want to know what are the lines that explain these very different outcomes. Is it the types of problems being solved? The harnesses? The programming languages? FWIW, my experience has been that among my cohorts of mid to deeply experienced developers working in the domain of experimental physics, all have leveled up various degrees after adopting Sonnet and Opus level LLMs using claude code CLI in Python, C++ and web tech, small scale scripts up to multi-package novel system develop and green field as well as incremental development and code maintenance.

What is "AOT"?

Maybe it was a thing from before clock speeds saturated and Moore's law mutated into being satisfied by ever increasing core count? It could have been useful when spec'ing hardware with the goal of running multi-threaded jobs that scale both their throughput and RAM requirements linearly with number of threads. That would make it sort of a continuous version of the more discrete GB/core rule of thumb. However, such linearly-scaled MT jobs are a subset of all MT jobs. And, ST jobs are not covered. A 2GB ST job on a 1GB / 1GHz machine will again need two cores, wasting one. When run on a 5GB/5GHz machine the job needs only its one core but must waste 3GB.

In particle physics, as more of the code is being GPU-accelerated, there is now another integer ratio to worry about optimizing: CPU core per GPU device. Across the landscape, some jobs have zero GPU acceleration, others may need 100 cores to keep a GPU busy, or only 1 core. Yet others can tune their CPU/GPU ratio to optimize throughput given what hardware ratio a given facility provides. Only a fraction of the software in the ecosystem takes up this challenge.

Most physicist pretending to be software developers or vice versa who are involved in the field do not consider any of these computing realities. At some level, that's natural and excusable. It's hard enough to develop the simulation and reconstruction and analysis algorithms. Simultaneously optimizing their implementation for throughput on a given hardware assumption is even harder. Harder still is to do that optimization over the variety of hardware assumptions. There are only a few cases where this holistic thinking has driven the design of the software.

> cuts harsh wind noise

They look a little silly but cat-ears work surprisingly well.

In particle physics, processing jobs face a limit of about 2GB/core. This is driven by the realities of "grid computing". The hardware in the computing facilities have approximately 2GB/core and jobs allocate based on number of core. This ratio has been fairly stable for a long time. Some facilities may have a bit more RAM per CPU core but 2GB/core is the general rule of thumb. I hazard a guess that this will not change throughout the (hopefully small number of) years that this memory cost bubble persists. In fact, the increase in cost may lead some facilities to keep older hardware going beyond its EOL/warranty period, prolonging a ratio that may actually be relatively generous compared to today's hardware systems.

As a consequence of this fixed RAM/core ratio, substantial software development effort goes to either making jobs fit in 2GB or if that is not possible then to utilize multithreading. Generally, particle physics processing does not particularly benefit from MT except in this fixed RAM/core situation. Sometimes large memory jobs are needed (inherently or because of bloat that is too costly to improve). When run on the "grid", these jobs must allocate multiple cores just to get "their" memory. If those jobs can use the extra cores, overall throughput does not have to suffer.

That's for conventional software, which still makes up the bulk of the computing. The situation for the growing amount of GPU-accelerated software is different and more varied. One trend can be seen relating to VRAM. Research groups with easy access to big GPUs like A100 write code to fit or exceed the relatively copious VRAM limits of the data-center GPUs, while groups that lack easy access to DC GPUs but have access to more modest "gamer" GPUs write more advanced software that can fit the smaller VRAM. In some cases, they write the software so it can scale the computation, keeping GPU utilization high while staying just under the VRAM limit.

General budget crisis and limited resources in the particle physics field are in part responsible for all of this tailoring of the software to fit the hardware. If better funded, particle physicists could spend more time doing physics and less time squeezing last drops of processing power.

Yes, the spam arms race is a really good analogy. In that light, my thoughts are aligned with heuristics that might be applied with procmail or in the original, pre-learning, spamassassin.

A fight-fire-with-fire is to insert an LLM to judge and/or respond to new pull requests and issues. This brings its own risk as it lets anyone who can make a PR/issue inject a prompt. It would also put one more wedge between the real human contributors and the real human developers.

A "humanity score" could also be an ingredient. GitHub or 3rd parties, could maintain a score of how human an account is. The "humanity" of all text produced by an account could be judged by LLM and/or humans. This could be centralized or based on a web-of-trust. Actually, I'd also like to have such a thing for reading HN and reddit comments.

But still, any system we can dream up can be attacked and we are back to an arms race.

I think everyone / every project needs to adopt a strategy consistent with their values.

Unfortunately, I see the choice space here as having "developer effort" anti-correlated with "negative repercussions".

On one end of the distribution, a "hair trigger ban" strategy is low-effort for the developer but will have some fraction of false positives and some fraction of those impacted will complain to "the socials" and some fraction of those complaints will gain traction and, as we have seen, can unfairly taint the project or worse. Responding and managing the false positives also requires developer effort, unless the developers can sustain a "fsck the haters" attitude.

On the other end of the distribution, the developer can spends substantial effort to engage each submitter to ascertain and correct bad behavior, educate them on how they should engage other humans as a fellow human in this LLM era.

There is developer effort needed of different types along this distribution.

A divide-and-conquer strategy might go something like this:

- Rank each submission in some low dimension space (llm<-->human, malicious<-->helpful)

- When enough samples are collected, perform clustering in this space to determine stereotypes, name these clusters, and develop mitigating strategies and implementations as needed.

Mitigations from easy/extreme to hard/accommodating could include:

- Hair trigger ban button.

- Copy-paste a link to an explanation in a comment before closing and/or banning.

- Customized explanation in comment before closing and/or banning.

- Link or customized explanation of what must be done to move the sample to a more favorable category and close/ban if resistance or silence is returned.

- Ongoing engagement in the face of resistance or silence.

This "meta development" program to provide such a system/facility could of course be highly automated with LLMs, fighting fire with fire.

(Despite the length of this reply, it was written entirely by a random human on the internet and not an LLM).

> Basically, think of this not as the CLI program saying to an agent "answer me this question" or "edit this file for me", but rather, the CLI program popping open a mini "guided + 99%-of-the-time automated" TUI coding-agent micro-IDE "inside" the workflow, in about the same way that git pops open your EDITOR inside `git commit`.

Isn't this simply having your mechanistic script call `claude "Prompt that is well honed to provide a mini, guided, 99%-of-the-time automated LLM action to $THE_THING"`? And, possibly including some `--allowed-tools`?

> The target codebase is very large.

But, does every prompt need the entire codebase?

"microsoft", okay, off to a great start. First click in the ToC that looks interesting and something I'd actually like to know as a RUST outsider:

    Common Python Pain Points That Rust Addresses

But then number one:

    1. Runtime Type Errors
    
    The most common Python production bug: passing the wrong type to a function. 
    Type hints help, but they aren’t enforced.

Uh, okay. This rarely if ever has been a problem for me and I don't usually even use type hints.

Then comes calling out the existence of None, the GIL and packaging as common "pain points". None of these have posed any problem to me essentially ever. Packaging used to be honestly annoying but since uv hit the scene, not at all.

I should have known better and stopped after reading "microsoft".

> They do need to have some form of dedinator

And some dedotaded wam.