Because an error is not an email?
8,992 karma · joined September 17, 2009
one of these things is not like the other
I agree with the author, I usually do not care how exactly the fetch call looks like. Whatever indeed.
It absolutely is, but that is besides the point
> Also, good packages tend have a team of people maintaining it. How is that the same exactly?
The famously do not https://xkcd.com/2347/
Everybody agrees that e.g. `make` and autotools is a pile of garbage. It doesn't matter, it works and people use it.
> It's not random, there's an algorithm for picking "good" packages and it's much simpler than reviewing every single line of LLM code.
But you don't need to review every single line of LLM code just as you don't need to review every single line of dependency code. If it works, it works.
Why does it matter who wrote it?
It may be bad practice, but consider that the median developer does not care at all about the internals of the dependencies that they are using.
They care about the interface and about whether they work or not.
They usually do not care about the implementation.
Code generated by LLM is not that different than pulling in a random npm package or rust crate. We all understand the downsides, but there is a reason that practice is so popular.
I'm working on a few toy projects and I am using LLM for 90% of it.
The result is 10x faster than if I coded it "by hand", but the architecture is worse and somewhat alien.
I'm still keeping at it, because I'm convinced that LLM driven code is where things are headed, inevitably. These tools are just crazy powerful, but we will have to learn how to use them in a way that does not create a huge mess.
Currently I'm repeatedly prompting it to improve the architecture this way or that way, with mixed results. Maybe better prompt engineering is the answer? Writing down the architecture and guidelines more explicitly?
Imagine how the whole experience will be if the latency was 1/10th of what it is right now and the tools are 10x better.
it will be WASM-containerized in the future, but still
Rubber-stamping is not really "reviewing" though.
And leaving a comment "I don't have enough info to review this properly" is a valid review as well. It signals that somebody else needs to pick it up.
> I fear that compounding that by layering on another obligation to the star team members would further push them out.
I get it, but I don't see an alternative.
1. the company culture must value reviews as work, probably even more important than coding
2. the reviewers must be allowed to respond with "I don't feel comfortable reviewing this because I don't have enough context"
Clearly the merger and approvers are responsible
for instance, people like Minecraft-generated worlds even though no human has crafted them
> ... therefore a computer must make all management decisions
They are nodes in a graph, where the other nodes are the input types, output types and other functions.
It makes sense to cluster closely associated notes, hence Modules.