75dev

Exploring Django Tasks

James Shuttleworth — Mon, 09 Feb 2026 13:49:13 GMT

Recap on where things stand

With the release of Django 6 and above, a new task framework has been introduced. Despite what some articles might suggest, this framework is not immediately beneficial for production environments and does not represent an instant "game changer." Instead, it marks a positive step towards creating a back-end agnostic interface for queuing tasks.

Currently, the framework only includes a dummy and immediate back end. As a result, it does not serve as a replacement for established solutions like Celery.

If all you want is a step-by-step guide to using named queues, skip down to “the quick guide to custom queues.” Everything else is just documenting my exploration in the hope it helps someone else get there faster.

Django Tasks and `django-tasks`

If you google for information, you’ll find the Django documentation on tasks as well as many tutorials that refer to the django-tasks package.

The django-tasks package is an implementation (“backport” it is described as) that many tutorials refer to as a way to use a database back end and a way to run a task completion process. I can’t comment on whether this is “production ready”. The tutorials suggest “manage.py db_worker" as the way to run this, which feels like suggesting manage.py runserver is acceptable for production. But that’s for later exploration. At the moment, the docs say:

Prior to 0.12.0, django-tasks-db and django-tasks-rq were also included to provide database and RQ based backends.

So I’m not sure most of the search results for how to use Django tasks to run background tasks are valid at this point.

Everything in this article, though, is based on using the task framework built in to Django>=6 but seems to be identical if you’re using the django-tasks package. And the README.md for django-tasks is really useful for understanding the basics.

Queues

I’m trying out the new task framework in a hobby project. I decided I would make use of the queuing system. At the moment I only have one kind of task, but I may add other tasks later just because it will be there and available.

There’s a note that if you change the queues enable you would get an InvalidTaskError exception. This caught me out because the phrasing is:

Enqueueing tasks to an unknown queue name raises InvalidTaskError.

My brain took that to mean that at the point of enqueueing, I would get an error. This is not the case.

So I added the section about queue names from the guide. At first this is not added to the TASKS settings dictionary. It also explains that in order "To disable queue name validation, set QUEUES to []." See below for more info on this below - I did some experimenting to ensure my understanding was correct before moving on, and it might be useful for others to see how that went.

django.tasks.exceptions.InvalidTask: Queue 'default' is not valid for backend.

This is not the same as the InvalidTaskError and I was a bit confused. The issue was, it turns out, that the decorator for the task function needs to specify the queue. As the file containing the task function is evaluated, the exception fires. I’m assuming the InvalidTaskError is somehow triggered if you enqueue some other way.

The quick guide to custom queues

Everything else in this post is about my exploration - realisations, mistakes and thoughts included. But here is the quick guide to using custom queues with the task framework:

Add the queue name to the QUEUES list in settings.
Decide if you want any existing task definitions to continue using the default queue. If so, make sure the QUEUES list also contains ”default”.
Add the queue_name to the task decorator

Here are the key pieces of code:


# In settings.py
TASKS = {
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",
        "QUEUES": [
            "my_queue",
            #Uncomment below to keep existing tasks using the default queue
            #"default",
        ],
    }
}

# In tasks.py
from django.tasks import task

@task(queue_name="my_queue")
def some_task(id):
    """Task for doing something with an object with given id"""
    pass

Absence of `QUEUES` is not the same as empty `QUEUES`

You can skip this section if you don’t care about how I proved to myself that I understood how queue validation worked.

From the django-tasks README.md (at the time of writing: 09-02-2026),

"To disable queue name validation, set QUEUES to []."

You might assume this means that without an explicit QUEUES list in the TASKS settings dict, there is no queue name validation but that’s not the case.

After I’d realised my mistake with the queue_name parameter, I experimented.

I figured there were multiple states of the QUEUES list that mattered. Not having one (1), having one with just the new queue name (2), having one with just “default” (3), having both (4) and having it as an empty list (5).

# 1
TASKS = {
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",
    }
}
# 2
TASKS = {
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",
        "QUEUES": [
            "my_queue",
        ],
    }
}
# 3
TASKS = {
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",
        "QUEUES": [
            "default",
        ],
    }
}
# 4
TASKS = {
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",
        "QUEUES": [
            "default",
            "my_queue",
        ],
    }
}
# 5
TASKS = {
    "default": {
        "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",
        "QUEUES": [],
    }
}

Then the task decorator could either not specify a queue (1), specify default (2) or specify a new queue name (3).

# 1
@task
def my_task(id):
    pass

# 2
@task(queue_name="default")
def my_task(id):
    pass

# 3
@task(queue_name="my_queue")
def my_task(id):
    pass

As it happens, it seems 1 and 2 are identical, which makes sense. By default, the queue is “default”.

	Default queue in decorator	Custom queue name in decorator
No QUEUES setting	️✅	❌
Custom queue only	❌	️✅
Default queue only	️✅	❌
Default and custom queues	️✅	️✅
Empty QUEUE list	️✅	️✅

Where does this leave us?

For my own exploration, I now have something that works with the new framework and I'm hopeful that with a combination of django-tasks and django-tasks-db I will have something that functions for background tasks. When I get to that point, I will have to dig into what might be safest for running in production. Can I really just use db_runner? Or will I have to roll my own task process? Or maybe there are other packages I can use to handle the tasks from the DB?

When I get time, I'll find out and post.

Too Many LLM Anecdotes Without Illustration

James Shuttleworth — Fri, 06 Feb 2026 13:56:14 GMT

Lately, there has been an overwhelming number of articles discussing AI tools for developers. These articles often follow a familiar pattern: they speak in broad terms about AI's impact, either positively or negatively, but rarely provide concrete examples of how these tools are being utilized. Key details such as the specific tools being used, the costs involved, the problems being addressed, and the methods of evaluation are frequently omitted.

The comments on these articles also typically fall into three categories: those who found AI for coding to be ineffective, those who consider it revolutionary, and those who believe it is beneficial for specific tasks if applied correctly. However, these comments often lack clarity on the programming tasks being tackled, the platforms or services employed, the associated costs, and the evaluation processes and so on.

The insights from individuals experimenting with AI tools are incredibly valuable. Yet, without detailed information, it's challenging to extract more than a general understanding that there is a wide range of tasks, workflows, and tools that, when combined, produce varied outcomes.

It's unlikely that those who praise AI coding assistants do so merely because they are poor programmers. Similarly, it's improbable that those who dismiss AI tools simply don't know how to use them effectively. The notion that selective use of AI tools only addresses a specific class of programming problems also seems far-fetched.

Apples and Oranges

From the articles and comments, it's easy to assume people are disagreeing about AI as a programming support tool. But the reality is they are often only arguing for or against the tool they have used. There are people who are using suites provided by the big AI providers, such as Cursor, while others are copying and pasting their files straight into Claude, and everything in between.

There are studies that examine the efficacy of AI tools, which are intriguing but often lead to the same types of comments mentioned earlier. Additionally, many articles from AI companies lack thorough research and tend to be more about marketing than providing an open comparison of tools.

What Would I Like to See?

What I'm really interested in is understanding what people are actually doing with these tools. What does their setup look like? What types of code is suitable for delegation to an LLM chat interface or agent? Are discussions about the performance of different models or modes useful, or is it the tooling that makes the significant difference?

Moving Toward More Deailed Discourse

The rapid growth of AI programming tools and models indicates that we are still in the early stages of development. I hope we can eventually reach a level of discourse similar to that of platforms, frameworks, and languages. For instance, no one claims Rust is superior to Go simply because it feels better, nor do they promote a new framework just because it seems more nuanced and responsive compared to the current best-in-class.

There’s no real criticism intended here. I didn’t intend to write one of those “Everyone’s doing X wrong, and here’s why” articles. The whole point of this blog is trying to think and reason publicly, add to the conversation and consciously try to contribute.

I've been experimenting with Qwen Code and could easily share my opinions on various forums without thinking about it as a data-point for others trying to work out how best to evaluate and use the newarray of tools at our disposal. However, I intend to document my experiences and findings in this blog instead. Perhaps others are seeking the same understanding I am, and my insights can contribute by providing semi-reproducible claims.

Finding real, useful info is hard

James Shuttleworth — Thu, 05 Feb 2026 09:57:33 GMT

This isn’t about LLM-generated articles or rampant astroturfing. Those definitely contribute to the problem, but even without them, it can be hard to find good info on things. Especially if those things are software development.

TL;DR

Navigating the vast sea of information available to software developers can be daunting, especially when seeking guidance that bridges the gap between beginner tutorials and advanced expertise. While the abundance of resources is undeniable, the challenge lies in discerning the truly valuable insights from the noise. By sharing experiences, engaging with the community, and documenting our learning journeys, we can contribute to a more comprehensive understanding of the tools and frameworks we use. This article is a step in that direction, aiming to spark conversations and encourage others to think aloud, explore publicly, and ultimately, enrich the collective knowledge of the developer community.

Digital Natives

A friend and colleague and I used to give a talk together about how much information is available for people learning computer science and software engineering and yet people still need people to teach, guide and encourage them to become good software engineers and computer scientists. We talked about “digital natives” and how we used to believe that, any day now, a generation of learners would turn up to our seminars with all the basics covered, just from exposure to tech; and, how they never arrived. It was a fun talk that used the Wizard of Oz as a theme, which we stretched to fit in so many ways. Becoming all powerful, like Oz; pulling back the curtain; having what you needed all along; etc.

Abundance of Information

It’s now many years later and I’ve spent much of that time both teaching software development (among other things) and doing commercial development work. In that time, the amount of freely available information for developers has grown, but mostly in one end of the spectrum or the other, but not the middle.

If you’re a beginner or advanced hobbyist, you’re covered. First steps in any language or with whatever library, infrastructure or framework is out there and you can follow any number of tutorials.

If you’re a developer working with a particular stack and you need API docs, blogs on trends or expert opinion on current architectures, you will find plenty.

The Missing Middle Ground

But what if you sit in the middle? For example, you’re a competent programmer but need to now build a web application. Or you’re a web developer that wants to switch to a new stack. The writing on how to go from a tutorial or quick test to something that is production-ready, makes use of modern best practices and utilises the best-in-class components is missing.

Worse, you often find writing that is incorrect and usually in a way that’s hard to spot from the wrong side of the learning curve.

An Example: Django’s new Task Framework

As an example, and the instance that triggered this post, try looking for information on Django’s new task framework. Before Django 6.0, if you wanted to have activity that was not synchronous with requests, you had to either build something separate and find a way to make it work with Django (put it in the DB, have the worker use it as a queue, set fields when done, have the web front end check status, etc.) or use something like Celery.

It makes sense for Django to fold some kind of asynchronous task framework into its core, just like it has done with other functionality. I don’t think Celery will stop being important (it’s a fully-fledged system with an amazing array of features) but it is overkill for lots of solutions.

The Django developers have created the framework but so far stayed away from implementing the actual back-end functionality. Some people argue that this is the wrong move, but I think it makes sense. It leaves room for others to create pluggable implementations of the back-end and doesn’t make them wait until there is a back-end ready and that comes with core Django. Plus whatever might fill that gap in core Django would become the de-facto back-end for many projects, even if the fit isn’t right.

Now, try looking for information on the new Django task framework. There’s the Django documentation, which is good and correct but not really a guide to having an asynchronous task system up and running. There are many posts that follow the usual pattern of explaining things by way of a tutorial application that doesn’t explain why things are as they are, how to make it production-ready, etc. And you also find articles talking about how it’s revolutionary. How now you just need core Django to have all your task needs met, ignoring the fact that core Django doesn’t actually have an asynchronous task completion back-end.

There’s also Django Tasks which is an “implementation and backport of background workers and tasks in Django“ but doesn’t come with “production-grade guarantees”. It’s great, and the docs are good if you know what you want.

The Role of Community and Personal Contribution

To be clear, I don’t think the Django developers or the Django Tasks package developers are failing to communicate. I like the idea of separation of concerns. Django tells you about Django and it’s not up to them to say how it fits your needs, same with Django Tasks. The problem is the proliferation of repetettive tutorial and opinion writing on the subject that’s masking information on how to understand the capability of the Django task framework.

And this is where someone should say “then write it”. And I might. But not until I feel confident I can not give people poor information myself. And maybe that’s the problem. By the time I know the task framework inside out, have found out which back-ends are useful, well written and production-ready, probably started writing a custom back end that I won’t ever complete but benefit from the journey of writing, I’ll have lost the perspective I currently have. I’ll only see the correct paths, not the indecision. I’ll instinctively design things to avoid the obvious (from my new perspective) pitfalls without realising it, making me unable to vocalise them for others.

Moving Forward: Thinking and Exploring Publicly

This is where the past few days of thinking, reading and tinkering got me. This post isn’t the answer, but it is my first step toward providing something that is, I hope, helpful to someone, somewhere. I realised I used to find a lot of useful information on Stack Exchange, but that’s no longer the case. I find lots of good stuff on Hacker News and realised people visibly thinking about things was the real bonus. If there was more of that, I might find the record of someone who has already pondered similar problems and moved toward solutions, or solved the problem entirely. But more important than finding the lines of magic code that solves the issue is seeing how people think.

So, I now have a blog. It’s not my first. The others were all abandoned over the past few decades. This one might be abandoned in the future but for now I’m going to try to write down what could be useful for other people, while I’m in the middle of it.