Is this surprising in any way? People who let Claude Code attribute commits to itself are probably vibe coders who delegate all the work. It's expected that there will be a growing number of new projects.
Indeed, this is quite obvious on Claude models vs Gemini. I fully believe Gemini is more powerful model, but the post training process is nowhere near what Anthropic does, which results in Gemini being horrible at coding sessions, while Claude is excellent.
Fully agree. AI or not, it's still the human developer's responsibility to make sure the code is correct and integrates well into the codebase. AI just made it easier to be sloppy about it, but that doesn't mean that's the only way to use these tools.
Reviewing things is fast and smooth is things are small. If you have all the involved parties stay in the loop, review happens in the real time. Review is only problematic if you split the do and review steps. The same applies to AI coding, you can chose to pair program with it and then it's actually helpful, or you can have it generate 10k lines of code you have no way of reviewing. You just need people understand that switching context is killing productivity. If more things are happening at the same time and your memory is limited, the time spent on load/save makes it slower than just doing one thing at the time and staying in the loop.
Honestly if I'm just following what a single LLM is doing I'm arguably slower than doing it myself so I'd say that approach isn't very useful for me.
I prefer to review plan (this is more to flush out my assumptions about where something fits in the codebase and verify I communicated my intent correctly).
I'll loosely monitor the process if it's a longer one - then I review the artifacts. This way I can be doing 2/3 things in parallel, using other agents or doing meetings/prod investigation/making coffee/etc.
Any programmer needs to be able to approach a foreign code base and navigate through it to identify ab issue. Reading code and understanding what is going on is an essential skill.
They are referring to `anytype`, which is a comptime construct telling the compiler that the parameter can be of any type and as long as the code compiles with the given value, it's good.
It's an extremely useful thing, but unconstrained, it's essentially duck typing during compile time. People has been wanting some kind of trait/interface support to constrain it, but it's unlikely to happen.
Conceptually it's quite similar to how C++ templates work (not including C++20 concepts, which is the kind of constraining you're talking about).
I quite like it when writing C++ code. Makes it dead easy to write code like `min` that works for any type in a generic way. It is, however, arguably the main culprit behind C++s terrible compiler-errors, because you'll have standard library functions which have like a stack of fifteen generic calls, and it fails really deeply on some obscure inner thing which has some kind of type requirement, and it's really hard to trace back what you actually did wrong.
In my (quite limited) experience, Zig largely avoids this by having a MUCH simpler type system than C++, and the standard library written by a sane person. Zig seems "best of both worlds" in this regard.
I think we will be getting into an interesting situation soon, where project maintainers use LLMs because they truly are useful in many cases, but will ban contributors for doing so, because they can't review how well did the user guide the LLM.
* modelling a solution that is consistent with the existing modelling/architecture of the software and moves modelling and architecture in the right direction
* verifying that the the implementation of the solution is not introducing accidental complexity
These are the things LLMs can't do well yet. That's where contributions will be most appreciated. Producing code won't be it, maintainers have their own LLM subscriptions.
I still think there is value in external contributors solving problems using LLMs, assuming they do the research and know what they are doing. Getting a well written and tested solution from LLM is not as easy as writing a good prompt, it's a much longer/iterative process.
Some months back I would have agreed with you without any "but", but it really does help even if it only takes over "typing code".
Once you do understand the problem deep enough to know exactly what to ask for without ambiguity, the AI will produce the code that exactly solves your problem a heck of a lot quicker than you. And the time you don't spend on figuring out language syntax, you can instead spend on tweaking the code on a higher architecture level. Spend time where you, as a human, are better than the AI.
I don't know, I've had good experiences getting LLMs to understand and follow architecture and style guidelines. It may depend on how modular your codebase already is, because that by itself would focus/minimize any changes.
If an author of a PR just generated code with an LLM, the GitHub PR becomes an incredibly inefficient interface between a repository owner and the LLM. A much better use of the owner time would be to interact with LLM directly instead of responding to LLM generated PR, waiting for updates, responding again, etc.
As a project maintainer, I don't want to interact with someone's LLM. If a person submits a PR, using LLM or not, the person is responsible for any problems with it. How they respond to review is a good indicator if they actually understand the code. And if they used a bot to submit the PR, I'd simply consider it a spam.
Yep, the indirection through the PR author is almost always inefficient and error-prone unless the author is really knowledgable about the code (many aren't).
And in general a lot more people want to use LLMs to generate things than want to consume the things LLMs generate. Some of the more bullish people should think harder about this pretty clear trend.
Maybe a future direction will be the submission of detailed research, specifications and change plans for feature requests. Something that can be assessed by a human and turned into working code by both slides.
I wonder if that is an opportunity to build an Open-Source platform focused on this, replacing GitHub as the collaboration platform of a time where code was valuable.
that's already happening tbh. the real issue isn't hypocrisy though, it's that maintainers reviewing their own LLM output have full context on what they asked for and can verify it against their mental model of the codebase. a random contributor's LLM output is basically unverifiable, you don't know what prompt produced it or whether the person even understood the code they're submitting.
How is that different than before LLMs? You have no idea how the person came up with it, or whether they really understood.
We are inventing problems here. Fact is, an LLM writes better code than 95% of developers out there today. Yes, yes this is Lake Wobegone, everyone here is in the 1%. But for the world at large, I bet code quality goes up.
Some sort of LLM audit trail is needed (containing prompts used, model identifier and marking all code written by LLM). It could be even signed by LLM providers (but that wouldn't work with local models). Append only standard format that is required to be included in PR. It wouldn't be perfect (e.g. deleting the log completely), but it might help with code reviews.
This would probably be more useful to help you see what (and how) was written by LLMs. Not really to catch bad actors trying to hide LLM use.
This would be a useful feature to bake into the commits generated by agents. Heck you don’t even need to wait — just change your prompt to tell it to include more context in its commit messages and to sign them as Claude rather than yourself…
some projects (I came across Mastodon's policy[0] which they say was inspired by ghostty and others) which have a more relaxed policy of basically "LLMs are ok so long as you understand what they did, and you own it".
But I think different projects have different needs.
The GPL talks about "the preferred form for modification of the software", and I'm starting to think that anything which involves any kind of LLM agent should be including all the text that the user gave to it as well. Prompts, etc.
Of course, even then it's not reproducible and requires proprietary software!
I still think the source code is the preferred form for modification because it is what you point the AI at when you want it to make a change.
Sure there might be md documents that you created that the AI used to implement the software, but maybe those documents themselves have been AI written from prompts (due to how context works in LLMs, it's better for larger projects to first make an md document about them, even if an LLM is used for it in the first place).
As for proprietary software, the chinese models are not far behind the cutting edge of the US models.
Except the GPL is dependent on the author having copyright over the original software but the output of an LLM may not be covered by copyright as a derivative work.
The "interesting situation" is that maintainers are unable to cheaply distinguish slop from good contributions so they will simply stop accepting outside contributions.
This will cut off one of the genuine entry points to the industry where all you really needed was raw talent.
I really wanted to like Helix, it's a great software, works out of the box. I dedicated energy to unlearn my vim habits and learn the helix way. I'm now able to use it fairly effectively, but eventually I just came to the conclusion the bindings are done the way they are due to simpler implementation, not simpler user interface. I'm back to neovim for small updates and zed in vim mode for larger code editing.
Have you tried Ki Editor[0]? It seems to be more into direction that you are looking for. It is not as mature as the rest of the editors but the editing model is definitely an improvement from ux perspective
Hadn't heard of this. So I looked at the docs for Ki.
I see the "Why Ki?", and then it has this:
> Being first-class means that it is not an extra or even sidekick; it is the protagonist.
Eh.
I find it quite off putting.
I guess my expectation is that someone enthusiastic enough to write a text editor with a value proposition of "it's got good tree-sitter-based navigation" would want to discuss why they thing syntactic selection is neat.
Seeing cliche LLMisms doesn't signal the same level of care to me.
Having been in the community for some time, it is just how the authors are, very enthusiastic about the wording. They like to come up with some wild terms explaining different behaviors and reasoning behind those behaviors, like "positional coherence" or "behavioral asymmetry", and the term "kimmunity" to reference to ki editor community. On a surface level, sure, it looks LLM generated, but I would be very surprised if they used LLM to generate that sentence. I choose to look at the actual meaning of the content and what they are trying to do differently
To some extend that is true for any opinionated piece of software. But that is a beauty of opensource don't use it if it doesn't match your idea of how that software should look like
It's not generated by LLM, it was actually my idea, but grammar-corrected by LLM, but you are not wrong either, the docs are really subpar in a lot of ways, and not clearly explaining why is one of them, and of course, the potentially cringey sentences too, someone complained the docs read like a Vogue magazine before lol
I sincerely respect your humility, it's refreshing. I doubt I'll have time to try out Ki any time soon, but it's been bumped up the infinite TODO list :)
Not having to deal with neovim plugins is a HUGE win. Using neovim with plugins feels like using a rolling Linux distro, you never know what breaks next. That's what I use zed, personally. It's the best modern vi-like editor, in my opinion.
Yeah I always see this "issue" with Neovim and its almost entirely user-cultural, installing big blobs of plugins, updating to edge every day and some kind of jones's pressure.
These days you can probably install mini.vim to get basically every paper cut fixed (eg extra "surround objects", aligning text, plugin manager etc), a theme, a few other assortments to taste and park your plugins at known commits or include them in your dotfiles and its ... fine. I haven't updated my plugins in probably 6 months and when I do I update them selectively only if there is actually a reason to do it or the changes are very minor.
I just use neovim ;)
Just commented to inform.
But I can see the benefit of something like evil-helix, very limited setup being needed and getting features like LSP out of the box …
>eventually I just came to the conclusion the bindings are done the way they are due to simpler implementation, not simpler user interface
This was my general feel from using it for a bit too. I don't think that necessarily makes it a worse result (there's a form of user-facing consistency in 'this implements like that', it's just a bit meta), but it's one of the things that constantly pushed me away a bit. Some semi-common actions just didn't feel ergonomic, even after a couple weeks. (not implying that vim is a bastion of perfection, of course)
That said, I HIGHLY recommend people give Helix and/or Kakoune it a try. The different mental model is immediately compelling in some ways, and on balance I think it's a better approach. It's just that you have to weigh the details that might not work for you against all the other IDEs out there that have a heck of a lot more stuff already built for them... and it may mean you don't keep using them. Or you'll be thrilled with the end result.
I'm a very long time user of vi/vim, and I've gotten tired of maintaining vim configs. I've gotta have my LSPs and treesitters. I decided I wanted to move away from self maintenance and use something opinionated.
But, I found helix a little too opinionated. In particular, when you exit and go back into the file it won't take you back to where you were. I decided I'd start using helix on my "work journal" file which is over 20K lines and I edit somewhere towards but not at the end (done is above the cursor, to do and notes are below). Also, I NEED hard line wrapping for that.
Helix doesn't seem interested in incorporating either of those, which were "must haves" for me.
So I set the LLMs on it and they were able to make those changes, which was pretty cool. But I ended up deciding that I really didn't want to maintain my own helix fork for this, not really a plus over maintaining my vim config.
The different bindings vs Vim was actually what stopped me using it. I really really wanted to love it and love a lot of the motivation and principles behind it, but unlearning decades of muscle memory is an absolute nightmare.
what do you mean it does not have a simpler user interface? I found the combo of hx for quick edits/terminal work and Zed with hx bindings for everything else great.
I'm much younger, just 42, but due to other medical problems, my attention span was being reduced. I've been programming profesionally for about 25 years, but the last years I was putting myself more into other roles, because being able to focus on code for a few hours uninterrupted is a luxury that I don't have anymore. I was honestly thinking I'll have to retire early. That was until I've tried Claude Code last year. It feels like a superpower. I can guide it, I can review it, I don't need it for thinking, I need it for writing code and under very strict guidance, it does that well. I feel like this extends the years I can do software well into to the future. In a way, I welcome masses thinking AI can produce software on it's own, it gives me hopes for more earning in the future for me.
reply