I feel this way about code. Writing things by hand is the quickest way for me to fully understand it, and that is what I am paid to do, to understand it. It will be executed millions and millions of times for every time it is modified, so even if writing it by hand is 10x or 100x as slow, it is still a better payoff.
> “why engineer something fundamentally well at the start if there it is zero cost to fix it later when problems actually show up?”
Because this is a myth. it is not true that there is zero cost to fix it. LLMs become less effective the more convoluted codebases become just like humans, if only at a different rate.
Is there something about an LLM that makes it incapable of simplifying a codebase? I have only seen that the slop jockeys who wield LLMs most ardently don't seem to care about that, and that older models were worse at everything, including that.
I try this really hard but it seems that getting an LLM to simplify a code base meaningfully is a much harder problem than getting it to output mostly functioning features very quickly.
They are great at adding but reducing takes much more hand-holding in my experience. Maybe this will improve, maybe it does not matter, maybe I am holding it wrong, I don't know.
I tend to think this is mostly because the training set has generally been "low quality code cranked out as fast as possible" and the goal has been "do more of that". After all, most code in general is mostly throwaway. And most frontier model labs are startups where code is short lived.
Different goals/context/training is all I think it takes to change this. Though yes, for now, I revel in my role as the one who can contribute a touch of elegance to the stupid robot's solution.
Edit: and yes, better models, but I think the Sol-generation are already good enough.
Weird, does not seem my experience. Then again we have loads of code where claude can look up our best practices and just copy it for another module, and we try to do everything as idiomatic as possible. Especially Opus 5.5 seems to be very good at this. It really is a step up even from Fable 5.1.
Also when doing a cleanup session we do give pointers where we see friction. That seems to help point it in the right direction.
No. Coding agents are great at simplifying, they just need to be told to do it.
I often see agents skip opportunities for simplification when not explicitly prompted. I have mixed feeling about this, but for now I think it's probably for the best that they stick to the script versus take initiative for things they haven't been told to do.
Copyright law varies internationally, which is especially tricky given we have the internet which can transfer copyrighted material between jurisdictions in the blink of an eye, but this is how one jurisdiction might approach it:
In Germany, there has been a long standing legal dispute between the band Kraftwerk and the musician Moses Pelham about him sampling 2 seconds from Kraftwerk's track "Metall auf Metall" (if you search for this term, you will get a lot of results about the dispute) without permission. This disputed has steadily escalated until it reached European Court of Justice who delivered a judgement establishing a principle that Moses Pelham's use of the sample was legal, and covered by the copyright exemption for "pastiches" (a term that has been mentioned several times in this discussion already).
So, this work here might be a pastiche, meaning a European court might find that there is no compensation due. Or not, who knows, I am not a court and not even a lawyer.
A small addition: With effect from 1 August 2021, the German legislature has amended copyright law to explicitly mention pastiches.
§ 51a Karikatur, Parodie und Pastiche
Zulässig ist die Vervielfältigung, die Verbreitung und die öffentliche Wiedergabe eines veröffentlichten Werkes zum Zweck der Karikatur, der Parodie und des Pastiches. Die Befugnis nach Satz 1 umfasst die Nutzung einer Abbildung oder sonstigen Vervielfältigung des genutzten Werkes, auch wenn diese selbst durch ein Urheberrecht oder ein verwandtes Schutzrecht geschützt ist.
Section 51a Caricature, parody and pastiche
It is permitted to reproduce, distribute and communicate to the public a published work for the purpose of caricature, parody and pastiche. The authorisation under sentence 1 includes the use of an illustration or other reproduction of the work used even if this is itself protected by copyright or a related right.
Parody of copyrighted works can be fair use in the US, but whether this would count is borderline. Simply using Frog and Toad to tell an unrelated story wouldn't be parody, but there are jokes that tie back to the F&T books which help make the case that this is a real parody.
It also helps that this is not commercial and doesn't have negative impact on the originals.
THANK YOU. I’ve always felt this way about PR review. I feel like people
should write a natural
language description of the change, and every section of it should link to part of the diff, and every part of the diff should be linked to by part of the description. That or just leave a comment on every chunk of the diff.
You might have use for an issue tracker I've been building the past year and a half. It lets you inspect diffs inline in the ticket, and replay the board to see how the workflow evolved over time via a timeline scrubber.
It stores issues as an immutable event log in your repo, so you can go back and inspect the context behind a change without having to litter the code with comments. Helps with traceability of intent.
Oh my god thank you. I have been trying to put into words what is so draining about pair programming with claude, and “doing creative work to impart meaning to the words” is exactly it.
this seems like more anthropomorphizing. even if it has similar results often enough to be useful, next token prediction is not searching a solution space.
you even end with a paragraph saying “it’s not too dissimilar from what we do”. how is that not anthropomorphizing?
and if what we do isn’t “thinking” then what is or ever has been?
> next token prediction is not searching a solution space.
Interesting take. Next token prediction (via the attention mechanism) is a "walk" through the token embedding space. Searching the solution space is what it does, mathematically. It's how we take tokens x context length possible combinations and prune them to converge on viable answers so quickly.
Does it look like search at inference time? No.
With given weights, a given prompt, and a given random seed, you get the exact same answer. There's not much searching happening at inference...
The key is that most of that space is searched at training time. The weights implicitly prune the search space, blocking off or make certain token combinations effectively impossible. It's easy to think "we're just applying weights at inference time" without considering all the pre-work that's done to prune that search space.
Which is exactly why "thinking" traces (and randomization) are useful! They bust out of any local optima created by too-tightly-constrained models or system prompts. It's both useful and technically correct to speak of the process as a high-dimension combinatorial search.
I agree with the idea that the taste, for lack of a better word, was the only thing that ever mattered. What I disagree with is the idea that slop that is “good enough” is indistinguishable from something that is crafted is “indistinguishable by the market”. I think it is indistinguishable in the short term, but very distinguishable on a long enough time span. The same way that hacked together slop has always been “good enough” to close a ticket and even get someone a promotion, but later costs the company thousands of engineering hours to rewrite once it becomes completely unreliable, slow and impossible to modify. We’re just speed running that now. It’s the same battle engineers with “taste” have been fighting with sales teams and product managers and lazy teammates before LLMs, just in fast forward.
I started toying with perlin vector fields as a level design tool for a game idea, then became more interested in visualizing them than the game they were meant to support. this weekend i realized i think im making a (short) ~game in which you control a dust mote riding air currents, trying to gather enough water to fall back to earth as a raindrop
