> For something like Azure, people are nor fungible
What I've learned from a decade in the industry is that talent is never fungible in low-demand areas. It's surprisingly hard to find people that "get it" and produce something worthwhile together.
“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
- Edsger Wybe Dijkstra
When things become too complicated, no one dares to make new systems. And if you don’t make new systems ofc you have to learn system design the other way around — by fixing every bug of existing systems.
Right, like running a sanitation department for a city. Who wants to do that? No one, but it's pretty important and everyone will raise hell and almost riot when it's not working.
Totally. I’m in insurance. So much is unsexy but critical. And that’s where you see a lot of folks churning on core systems, process, etc that makes insurance actually work vs any headline tech/investment/AI stuff. Don’t get me wrong - wins there too. But 22 year old Harvard grads aren’t going for underwriting assistant jobs (to use an example)
A geographic area where there's not abundant opportunity for software developers. Usually everywhere outside the major metro areas. It was primarily meant to discount experiences from SF or Seattle where I'm sure finding talent is easy enough, assuming you are willing to pay.
> The bun team has already tested using git's C library and found it to be consistently slower hence resorting to literally executing the git CLI when performing bun install.
I find that to be a much more remarkable claim. Git doesn't have a C library, and even if it did, In which world is literally shelling out faster than a C library call? I suppose libgit2 could be implemented poorly.
If we follow their link[1] we get some clarity. It's an markdown (ai prompt?) file which just states it. Apparently they've "microbenchmarked" creating new git repositories. I really wonder if creating new git repositories is really on their hot path, but whatever.
Where does that claim in that random markdown file come from then? Well apparently, 3 years ago when somebody was "restructuring docs"[2] and just made it up.
I guess there really is a class of "engineers" that the AI can replace.
libgit2 is not nearly as thoroughly tested as the git CLI is, and it is not actually hard to imagine that calling the git CLI to create new repos is faster than shelling out to a C library.
referencing the commit where they removed the ability to link with libgit2 because it was slower.
Having built a service on top of libgit2, I can say that there are plenty of tricky aspects to using the library and I'm not at all surprised that bun found that they had to shell out to the CLI - most people who start building on libgit2 end up doing so.
I don't know what the bun team actually did or have details - but it seems completely plausible to me that they found the CLI faster for creating repositories.
I'm actually assured to hear the git CLI is better covered than libgit2 since the CLI test suite is what I used as my "validation" for progress on meeting git's functionality
As for what happened with Bun and libgit2, my best guess honestly is smth to do with zig-c interops but don't doubt there are optimizations everywhere to be done
> Your comment does not seem to be in good faith, implying that they've made up the performance difference.
I believe I have accurately represented what the article says. Had the article provided the comment you have just linked, I would have commented on that as well. I did not intend to imply that they manufactured the performance difference, merely that they don't know what they are talking about. The thought I have in my head is that they are incompetent, not that they are malicious.
I wholeheartedly agree that libgit2 is full of footguns, that's why it matters that it's not actually "git's own C library" but a separate project. I also agree that you usually end up shelling out to git, exactly because of those problems libgit2 has. If those problems aren't speed though, and I don't think they are, the blog post would have to cover how this reimplementation of libgit2 avoids those problems.
I'm not here to litigate if bun would be faster with libgit2. I am however here to make the argument that the blogpost does not make a convincing argument for why libgit2 isn't good enough.
Bun's attempted to integrate with libgit2 instead of spawning calls to the git CLI and found it to be consistently 3x slower iirc
The micro-benchmarks are for the internal git operations that bun rn delegates to CLI calls. Overall, network time (ie round trip to GitHub and back) is what balances the performance when evaluating `bun install` but there are still places where ziggit has better visible wins like on arm-based Macs https://github.com/hdresearch/ziggit/blob/master/BENCHMARKS....
I don't know what that "BENCHMARKS" document is supposed to show. When I try to replicate their results I'm getting wildly faster executions of standard git, and they don't provide enough details for me to theorize why.
I also noticed that their version of the "blame src/main.zig" command doesn't actually work (it shows all lines as not being committed). Sure, it's easy to optimize an algorithm if you just don't do the work. Git does indeed take longer, but at least it actually gives you a blame of the file.
For your context, I'm an AI hater, so understand my assumptions as such.
> The obvious best solution is to have your agent write release notes for your agent in the future to have context. No more tedious writing or reading, but also no missing context.
Why is more AI the "obvious" best solution here? If nobody wants to read your release notes, then why write them? And if they're going to slim them down with their AI anyway, then why not leave them terse?
It sounds like you're just handwaving at a problem and saying "that's where the AI would go" when really that problem is much better solved without AI if you put a little more thought into it.
For release notes in particular, I think AI can have value. This is because more than a summary, release notes are a translation from code and more or less accurate summaries into prose.
AI is good at translation, and in this case it can have all the required context.
Plus it can be costly (time and tokens) to both “prompt it yourself” or read the code and all commit logs.
If your process always goes PR -> main and the PR descriptions + commit messages are properly formatted, generating release notes shouldn't be much more than condensing those into a structured list with subheadings.
What better solution do you have in mind? This scenario is AI being used as a tool to eliminate toil. It’s not replacing human creativity, or anything like that.
If you have a problem with that, then you should also have a problem with computers in general.
But maybe you do have a problem with computers - after all, they regularly eliminate jobs, for example. In that case, AI is only special in its potentially greater effectiveness at doing what computers have always been used to do.
But most of us use computers in various ways even if we have qualms about such things. In practice, the same already applies to AI, and likely will for you too, in future.
In a lot of my AI assisted writing, the prompt is an order of magnitude larger than the output.
Prompt: here are 5 websites, 3 articles I wrote, 7 semi-relevant markdown notes, the invitation for the lecture I'm giving, a description of the intended audience, and my personal plan and outline.
Output: draft of a lecture
And then the review, the iteration, feedback loops.
The result is thoroughly a collaboration between me and AI. I am confident that this is getting me past writer blocks, and is helping me build better arcs in my writing and lectures.
The result is also thoroughly what I want to say. If I'm unhappy with parts, then I add more input material, iterate further.
I assure you that I spend hours preparing a 10_min pitch. With AI.
Great example. Just give me the links you would give to the LLM. I also have an LLM and can use it if I want to, or I can read the links and notes. But I have zero interest in reading or hearing a lecture that you yourself find too tedious to write.
You have less interest in sifting through multiple articles and wiki pages sent to you by a stranger with a prompt than the one paragraph same stranger selected as their curated point.
And pretending like you’d act otherwise is precisely the kind of “anti ai virtue signaling” that serves as a negative mind virus.
AI is full of hype, but the delusion and head in sand reactions are worse by a mile
No pretending here. I don't ever ask an LLM for a summary of something which I then send to people, because I have more respect for my co-workers than that. Nor do I want their (almost certainly inaccurate) LLM summary. It's the 2020s equivalent of "let me Google that for you": I can ask the bag of words to weigh in myself; if I'm asking a person it's because I want that person's thoughts.
Then let him curate it as his central point. If he finds even that too tedious to do, I absolutely have no interest in reading the output of a program he fed the context to (particularly since I also have access to that program)
The original comment was saying that the AI would be both the writer now and the reader, in future. That's how the toil is eliminated. Instead of reading or searching through a series of release notes, you can just ask questions about what you're specifically looking for.
> If writing something is too tedious for you, at least respect my time as the reader
"If comprehending something is too tedious for you..."
Seriously, don't jump to indignant rhetoric before you're sure you've understood the discussion.
What's the point of the AI writer in that use case? Just send your prompt to my AI. And for that matter since prompting is in plain English, why not just send your prompt directly to me, and I'll choose to prettify it through an AI or not as I prefer.
The point is that it summarizes the context. It’s an important optimization, because context and tokens are both limited resources. I do something similar all the time when working with coding models. You’ve done a bunch of work, ask it to summarize it to the AGENTS.md file.
The more fully automated agents rely heavily on this approach internally. The best argument against it is that good harnesses will do something like this automatically, so you don’t need to explicitly do it.
Sending you the prompt wouldn’t help at all, because you’d have to reconstruct the context at the time the notes were written. Even just going back in version control history isn’t necessarily enough, if the features were developed with the help of an agent.
But I also have access to an AI that can summarize content. So why not just send me the content and the prompt you used? Or just the content, so I can summarize it however I want?
Obvious better solution is to either a.) not write those release notes b.) try to figure out release notes format and process that leads to useful release notes. Once it is useful, you can decide to automate it or not - and measure whether automation is still achieving the goal.
What OP did was "we lacked communication, then created ineffective process that achieved nothing, so we automated the ineffective process and pay third party for doing it".
If you pay tokens for release notes that nobody reads, they you may just ... not pay tokens.
This is kind of a fundamental issue with release notes. They are broadcasting lots of information, and only a small amount of information is relevant to any particular user (at least in my experience).
If I had a technically capable human assistant, I would have them filter through release notes from a vendor and only give me the relevant information for APIs I use. Having them take care of the boring, menial task so I can focus on more important things seems like a no brainer. So it seems reasonable to me to have an AI do that for me as well.
I read a lot of release notes in my job and the idea that that is some kind of noticeable time sink that needs to be streamlined is bizarre to me. Just read the notes.
Working with a team of SREs using LLMs to troubleshoot production issues and holy shit - the rate at which it uses that exact language and comes to completely fabricated or absurd conclusions is close to 80-90%
> Nontechnical people simply don't have any idea about what LLMs are.
We need to be very very careful here. Just like advertisements work, weather you think you're immune or not, so does AI. You might think you're spotting every red flag, but of course you think so. You can't see all the ones you missed.
Do not make the mistake of thinking that being techy somehow immunizes you from flattery. It works on you too.
> The goal is to give the answer that would have come from the training data if that question were asked.
Or more cynically, the goal is to give you the answer that makes you use the product more. Finetuning is really diverging the model from whats in the training set and towards what users "prefer".
What I've learned from a decade in the industry is that talent is never fungible in low-demand areas. It's surprisingly hard to find people that "get it" and produce something worthwhile together.
reply