Folks are increasingly using LLMs to generate PRs for Django.
We’re asking folks to declare that usage, and often they do, but I still see a lot of commits (not necessarily just in Django) that are clearly (at least largely) LLM generated but not so attributed, via e.g. co-authored-by lines in the commit message or any other mechanism.
I think we’ve just drifted into accepting such contributions without having had a clear community discussion about that, and whether, and to what extent, Django wants to accept LLM contributions, in core, and elsewhere.
@CodenameTim posted recently on the topic of Why use open source at all?:
I’ve also been rereading the recently updated 6th Edition of @wsvincent’s Django for Beginners.
As such, and given the developments in the last couple of years, I’ve been thinking about what Django provides for me, and why skill and expertise still matter, even with the new tools that are available.
Yesterday, we were recording Django Chat with @hakib. The topic of Django’s API story came up. What about if we just got Opus 5.5 to write one for us? was the question at one point.
Now @FarhanAliRaza has already done this: Django-Bolt — “Faster that FastAPI. Still Django” 
— is a phenomenal project: a ridiculously fast Rust based Django API framework, written with significant LLM assistance, right Farhan? (I think I recall other projects in this space, but they’re not coming to mind immediately.)
Now, Django-Bolt is a great project, really exciting, but, I ask myself, how would I feel if Django just incorporated it, and declared that that was the long-awaited API story?
Or, to take another example, if we vibe coded a replacement for the ORM, how would I feel about that?
And I think the answer is that it would fundamentally undermine my faith in Django. It would cease to have a point, to adopt the dual of Tim’s argument.
I continue to use Django because it’s an absolutely solid and trusted foundation upon which I can do my work. The web problem is solved — we can add support for the new QUERY verb, and so on, but it’s done.
The interesting bit is what I do on top of Django. If I want to use LLMs there I can, but Django is the substrate: whatever mess the models come up with, Django is the foundation that lets me make sense of it, and stay in control. In this age of cheap code generation, it’s the known quality of the solid core that means something, not feature X, or Y, or Z, which I can have in moments just by asking for it.
I think there is a very real danger that we are drifting into a position where we incrementally undermine the quality and stability that constitutes Django’s value as the framework of choice, without having had the proper discussion about how to maintain that quality, and what limits we might draw on machine generated code where that might undermine it.
To wit, I think it’s long past when we should have had a bigger discussion about what our AI Policy should be. (I think we’ve somewhat been avoiding it, but I don’t see that as sustainable.)
It seems there are two schools: something like Twisted or Flask, which steer away, and then others, which seem to be accepting changes at ever faster rates.
My own view is something like this:
Whilst impressive, the output of even the latest models is deeply flawed, in ways that is often hard to specify. We all know it from LLM generated writing: well, so for code. It’s an empirical conjecture but, the kinds of issues I still see are largely unchanged over the last few years — they are better now, yes, but I’m not convinced the issues are going to disappear: these things generate next token, even in loops, and the lack of perspective seems fatal.
I see problems accumulate as LLM usage in a project increases. The ability to comprehend machine generated code diminishes, and the maintainability of that code diminishes with it.
In a commercial project, that can be fine. It’s all trade-offs. Faster velocity for slightly crappier code can be the different between profit and loss: actually shipping is of significant value.
But — and, again, this is my own view only — those trade offs apply above the foundation, above Django. There I need the known quality that I’ve always relied on.
To the extent that we allow Django’s coherence to erode, for its quality and maintainability to fall, we undermine the very reason to use it. Knock yourself out Claude, it’ll become “I need a web app” and not “I need a Django web app”, and at that point we can pack up shop.
Add ons? As I already said, I’m more receptive there: the splash-zone is contained.
As another example: I was talking with @jacobtylerwalls at Django on the Med about Django’s free-threading readiness. Having an LLM look for candidate problem areas, and stress test those, seems like a genuinely novel usage, that would have been difficult previously.
So, I don’t think plain refusal to engage is necessarily the right approach either.
The thing I’d like us to avoid is sleep walking into undermining the trust that people put in us. Ultimately, If it becomes a slop fest, that trust is gone. We’ll all just vibe up our own.
We have to have the conversation before that happens.
)
)