But I think the answer is not “don’t slop me, all you sloppers.” The better answer is closer to: “what problem were you trying to solve?”

There is no obligation to treat every PR as merge-ready code. A PR can also be a concrete issue report or a proof-of-concept for a bug. It can say: I found a problem, I investigated it, and code was the clearest way to show where I think the issue lives and how it might be addressed. Use or ignore the implementation as you like. Human-language descriptions are not always the best way to communicate something you've already traced through the codebase.

That can be a high-value contribution even if the code itself is not accepted. It moves the conversation from “I want X” to “here is where X touches the codebase, here is a failing case, here is a possible direction, here are the tradeoffs I noticed.”

The social contract should be that the contributor does not dump review debt on the maintainer. Mark it as a prototype. Explain the problem in your own words. Say what you tested. Say what you are unsure about. Be willing to revise or accept that the maintainer may throw the patch away.

But once framed that way, the relevant question is not whether AI was used. It is whether the PR reduces ambiguity or increases burden.

A sloppy PR that demands review is bad. A prototype PR that explains a real problem is often useful.

The screenshot is funny, and obviously the block is absurd, but the leap from “a safety classifier or routing layer misfired” to “Anthropic is leaning into the nanny state thing” feels like adding a lot of intent that the evidence doesn’t support.

Occam’s razor says this is probably just a dumb false positive somewhere in a safety stack. That’s still worth criticizing, especially because these systems can be brittle and overbroad, but it’s a very different claim from whatever the editorializing is suggesting.

Start with a set of work that's well specified and reasonably chunked to sizes that make it so that the review parts fit in the gaps of the working chunk and interleave (1-4 tasks of this). While the agent is working on the A task, you're reading the B task, only add a 3rd task if you're waiting on the agent excessively. Give yourself some slack on this to think about side quests (maintenance / tech debt / planning future work to your system etc.)

Make sure the handoffs are reasonably detailed (prompts / AGENTS.md instructions) - make your agents provide more context than normal - make them assume that you don't read all the text they spit out and need to be handed succinct summaries with information that helps reduce cognitive burdens (what I was doing, how I did it, what's next etc.)

It's reasonable to regularly ask the agent what things you've worked on choices made, options considered and discarded, context rehydrating. There's a lot of small tweaks you do when interactive prompting that get lost in a drift rather than captured as a neat single list. Make the agent help track that stuff. (at least prior to shipping, but often in intermediate steps.

Write flows that keep software in a buildable state so you can run it and queue up changes based on what you see. Avoid long periods of broken refactoring (caller code written before callee, deletion before add in a move etc.) Run quick checks (e.g. rust's cargo check) after each change, not at the end.

Correction of agent errors should end up as future steering. If the agent makes a mistake once it's the agents fault, twice it's your fault.

Leave time to stop and evaluate the current state regularly (where are we on the work). It's easy to mistake momentum for progress when you're the human part of an agentic loop.

Here that's not happening. The code being produced by the LLM is Rust, not C.

Tests often are exactly the information necessary to understand exactly what the output should be. See https://github.com/git/git/blob/master/t/t0000-basic.sh for an example of how detailed these tests are.

It would be reasonable to point an LLM at these and use them with a basic knowledge of git to produce a rust version of git in a non-infringing manner.

If you did this manually it would take a long time.

I'd say what we're talking about here is probably a fair bit different to modding a game in most aspects.

This is a bit stronger than the actual report where this has been discussed finds. See part 2 in https://www.copyright.gov/ai/ for details, but TL;DR, parts where humans have control over the expression may be copyrightable. But working out which parts those are is likely a difficult question (would likely require proof of provenance across many of those LLM sessions)

> “So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification...”

Here given that this is rust and the original expression is C, the implementations cannot be the same by definition.

Feel free to extrapolate to the threshold where it's not and at that point apply.

> you’re really having to duplicate the actual git internals

Copyright covers the expression, not the method. So the Rust function:

    fn sum(a: u8, b: u8) {
        a + b
    }

    int sum(int a, int b) 
    {
        return a + b;
    }

There's likely a threshold at some point. It's helpful to look at a minima and then continue from there though.

I'm curious if there's case law that supports your assertions here?

> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

So assuming that sum(a, b) is non-infringing and not combined to form a larger program (i.e. the tests aren't compiled into the grit code), then the GPL explicitly doesn't apply to this use

yeah fair - the "The canonical Git source code we're targeting to replicate the functionality of is in the git/ subdirectory." part makes this hard to argue against.

> To the extent the resulting work is a derivative of the test suite it is possibly infringing

It's this bit that I have a problem with. If I run the test, it fails and reports a failure. Now I write code and run the test again. What is the theory there that code that I wrote infringes.

Simplify this down:

Assume the following is copyrighted:

    fn test_sum() {
        assert_eq!(sum(1, 1), 2);
    }

    fn sum(a: u8, b: u8) {
        a + b
    }

Substitutibility probably doesn't apply here in the way you're implying and if it did it would likely be hampered by the 9th circuits findings about transformation in sony v connectix. Arguments here likely would look at rust not having a stable ABI, and hence not being inherently substitutable as a libray (grit-lib), less clear as an executable (grit-cli) on that side

basics of copyright law - the fundamental thing being protected is the expression... is a rust program's expression the same expression as a c program? I'd say generally not.