There is such a clear lack of innovation drive in this field. Every lab just copies what the other does. One of the most baffling things to me is how the once-upon-a-time good developer instinct to make everything reusable, testable, and deterministic is just getting lost into a sea of markdown begging a language model to please act a certain way. For example this repository has a "skill" definition that consists in instructing the LLM to run pre-commit checks. But we have solved this a long time ago, it's called git hooks. I do not understand why they don't simply wire those instructions as testable, reusable, deterministic code routines in the git tool call itself. It's like everybody is taking their brains out and putting it in a drawer.
This is exactly how almost every field evolves. We like to think we are so innovative. We aren’t. When someone finally does something slightly different that’s actually useful everyone comments how that was so obvious all along and they could easily have done that too . Hindsight and all. And for every new tech , people will always try to use it for everything, no matter how unsuitable, until the hype goes down and we have a clearer picture of where the tech should be used.
Using git hooks vs an LLM to run pre-commit checks does not require hindsight.
Every company gets a limited number of innovation tokens. Where they choose to spend them is up to them. Some companies spend them on the model harness, some, like DS, spend them on the model architecture etc.
https://mcfunley.com/choose-boring-technology
Yes this whole focus on customisation and plugins etc is really just laziness and the absence of innovation. I don't want an infinitely programmable IDE. I already have that it's called my computer.
I want something that actually has an opinion and gives me productive value without having to spend days reconfiguring it first.
First, cloning a repo doesn't bring the hooks with it - so it's not just as simple as saying "use git hooks".
Second, if the repo had hooks and instructions for the LLM or user to blindly install/enable the hooks, we'd instead be complaining about security risks and what might happen if the repo is compromised at some point in the future.
Third, sometimes you don't want to mechanically enforce things via git hooks because it impacts your use when what you're really trying to codify and enforce are the LLM's actions. In that case you can enforce mechanically via hooks at the harness level.
And finally, git hooks are a great solution for upstream repositories to enforce quality and protect branches. But it means that the upstream is the one running the checks. It makes the upstream a potential bottleneck - better to have the leaf nodes run the checks locally and fix any issues before pushing it upstream rather than push upstream, wait for results, make changes, push upstream, wait for results, make changes.
First, I'm SURE there are ways to send scripts from one computer to another over the internet.
Second, the point isn't about a specific repo, it's the general tendency to rely on fuzzy .md files scattered all over the place. And I really don't see how letting the output of a language model run a one time command is more secure than running a script.
Third, "nothing applies in all context"? Yeah, obviously. And harness hooks (at least with Claude code) are still more suggestions than anything else. The only way I've found is literally rejecting a tool use and forcing it to recall in the proper way, which of course makes for more token usage. I wonder who benefits from that.
Finally, no idea what you are arguing against. Use git hooks where they make sense, local or remote.
Yeah. LLMs have their place and they are definitely super human at short length tasks, but I feel like a large part of the "AI boom" is trying to get the computer to do something in a worse way then it already could.
But that "worse way" makes AI labs and investors a lot of money... If the perception that "worse" is accompanied with needing less human intervention, i.e. less labor, worse is better from a business perspective...
How does a git hook need more labor than an LLM?
I actually run into more issue with deterministic hooks. Ie one hook triggering before another and not letting the agent move forward. I agree that there is a place for deterministic hooks. But there also times when you need something closer to a recommendation that they agent can be reminded of but isn’t a hard block. Think of assigning something to a co worker. You can recommend a checklist of what to do before a commit but they will adjust if the situation requires it.
Gotta burn the tokens somehow! There’s a lot of these solved problems that devs have forgotten exist all in the name of using an llm for sake of using it.
Product-wise... maybe. I'm also seeing a lot of genuine attempts to reinvent programming around some form of new agentic paradigms.
But at the core science/tech of AI it's probably the most amount of innovation I've ever witnessed in a field. The pace of new developments is staggering.
Is it staggering? Given the amount of money being poured in it doesn't seem all that impressive at all. And the constant overhyping is not helping either.
They built the whole thing in 2 months with 2 developers. They are not gonna think about every feature with any reasonable thought/effort behind it.
The part that really annoys me is the stark difference in cost between harness usage and api usage. I'd like to build my own harness and maybe I just will and focus on local model serving
I remember a popular hn thread few yrs ago where a dev replaced their whole deployment pipeline with a prompt.
it was widely ridculed at that point but now i am not so sure.
Well, that makes one of us. Replacing deterministic processes that work with lossy processes makes no sense. You’re literally reinventing the wheel every single time, what are you talking about?
It's because things change, things break, they are misconfigured etc. Yes, if you have perfect deterministic tools in an unchanging and perfect environment, sure. But the deterministic tools need constant maintenance, fixing, reconfiguring, adapting to external changes, dealing with unexpected failure types etc. Not saying you should use LLMs for everything, but LLMs equipped with tool calling can often fix things. And they can also fold it back to a robustified script. That's the strongest use case. LLM checking errors, fixing the scripts, and the routine runs are via those scripts. It just checks that everything ran to completion or what kind of hiccup happened. I know this sounds terrifying from a job security perspective, but it's going to be a wild ride for all of humanity.
> what are you talking about?
oh i mean 'now i am not sure if it would be ridiculed'
"just trust the llm bro, it will figure it out" - no brains used here, its staggering...