Django should be the perfect target for code generation. The framework is organized, highly modular, well documented, and there is (should be) a very large number of projects to train on. While Claude seems to have a good grasp of the modular part, and knows the basics, it lacks the ability to take advantage of the finer details - the ones that change “good enough” into “fit for purpose”.
For a side-project, which was vanilla Django + HTMX, it excelled at the big picture stuff. After six rewrites (more on that later, perhaps), I had a very nice-looking, more or less working app, which did what I wanted, more or less. Lifting the lid, to see what was generated the results were like, however, was less impressive. A simple, paginated ListView, illustrated some of the things Claude does not seem to know:
- the
querystringtemplate tag can be used for generating next and previous links. - the
requestand currentvieware available in the template context. - accessing a potentially non-existent key or attribute in a template, does not throw an error.
- that ModelManagers are the natural place to add methods for common queries.
- that Models are the natural place to add additional properties or methods.
- instead of using
Queryset.distinct(), when generating a values_list() it will simply fetch every record and throw them into a set().
In addition, to generous use of utility functions, Claude also seems to have a fixation on python dataclasses, using them to map model attributes, onto, class attributes with output formatting applied, which makes it more difficult to change the way things are displayed in a template.
Since Large Language Models are simply statistical inference engines, none of this is surprising. Generic Views are “recent” when looking at the overall Django code-base the models were trained on, though that’s stretching the definition of “recent”. As a result they are likely to be under-represented in the probability distribution of possible solutions. It also seems likely that Claude is generating python rather than generating Django. This likely will change over time, but it begs the observation that if we had an LLM that specialized in Django, the task of making, (de-slopping) the generated code more idiomatic wouldn’t be necessary, and we’d end up with less, more efficient code, which consumed fewer tokens, and was easier to maintain by humans and machines. How many parameters would such a model need? Likely not that many, so it would comfortably run locally. The market is likely too small if an organization was looking for astronomical returns, but combining a framework with excellent code generation tools would appear to be a winning proposition. Is this on anybody’s radar?