We are extending the search for the Django Software Foundation's first Executive Director. Applications now close at the end of Tuesday, September 22, 2026, anywhere on Earth (AoE). As long as it is still September 22 somewhere, your application counts.

We are happy with the applications we received. We also knew several people had applications in progress, and it took a while for word about the role to reach everyone it should have. Giving people a little more time felt like the fairest option. If you were most of the way there, you have until Tuesday.

If you have already applied, this does not slow anything down for you. We are reviewing applications as they come in, and we will reach out to candidates and schedule interviews on the same timeline we planned.

The Executive Director will play a central role in helping the DSF grow its capacity and build a sustainable future for the Django project and its community. That includes leading fundraising and partnerships, supporting the Foundation's operations and programs, and working closely with the board, staff, volunteers, and the wider Django community.

We are looking for an experienced nonprofit leader who is comfortable taking on a broad role and building things as they go. Fundraising is central to this job. We need someone who is at ease sitting down with companies, making the case for Django, and connecting what the DSF does to what those organizations care about. Much of the Foundation's future depends on growing those relationships and turning them into steady support.

You don't need to be a Django or Python expert, and you don't need prior involvement in the Django community. Experience with open source or other community-driven organizations is welcome, but we are primarily looking for someone with strong fundraising instincts, plus leadership, communication, relationship-building, and organizational skills.

Could that person be you?

If you have been waiting for the right opportunity to step forward, we encourage you to review the role and submit your application.

And if you know someone who would be a strong fit, please share this with them. A great candidate may be just one introduction away.

See the full job description and application details.

If you are ready to help shape the next chapter of the Django Software Foundation, we want to hear from you. Applications close on September 22, 2026, anywhere on Earth.

16 Sep 2026 12:50pm GMT

fastlogging-rs: High-Performance Logging for many different Programming Languages

Logging is often the hidden bottleneck in your application.

Every log.info(...) call can block your hot path, serialize your threads, and slow down your I/O-bound workloads. That's why I created fastlogging-rs: a Rust-powered logging framework that is extremely fast, thread-safe, and available with a similar API in 8 different programming languages.

My first release, 0.8.1, is available with the following features:

• Initial release of the Rust core (fastlogging crate) with bindings for Python, C, C++, Go, Java (FFM and JNI) and C#
• Non-blocking, asynchronous logging - writers run in background threads
• Optional file rotation and compression
• Optional AES encryption for network logging
• Configuration via API or configuration file (JSON, XML, YAML)
• Automatic forwarding of log messages from sub processes to the main process

Why fastlogging-rs?

Because speed matters…

🚀 Significant Performance Improvements

Compared to Python's built-in logging module:

• Writing to a file is up to 147× faster
• Rotating file logging is up to 207× faster
• Even compared to Apache Log4j, fastlogging-rs is up to 9× faster

When your application logs millions of messages, these speedups can turn minutes into seconds.

Benchmarks results for writing to a file

fastlogging-rs file writer benchmark fastlogging-rs rotating file writer benchmark

🌍 One Framework, 8 Languages

fastlogging-rs is written in Rust and comes with thin wrappers for your favorite programming language. All bindings share a similar API, so you can use the same logging concepts across your whole stack:

⚡ Non-Blocking Architecture

Logging calls are non-blocking: each call performs a cheap level check (a single integer comparison, no lock) and hands the message to a channel. A background LoggingThread drains that channel and dispatches to each writer's own thread. The speed of your writers never slows down your application - as long as the queue doesn't run full.

🔧 Rich Feature Set

• Thread-safe logging calls
• Multiple writers (sinks) per logger: console, file, network, syslog, callback
• Optional file rotation and compression
• Optional AES encryption for network logging
• Configuration via API or configuration file (JSON, XML, YAML)
• Automatic forwarding of log messages from sub processes to the main process

Installation

Rust

cargo add fastlogging

Python

pip install pyfastlogging

Usage Examples

Rust

use fastlogging::{logging_new_default, LoggingError};

fn main() -> Result<(), LoggingError> {
    let mut log = logging_new_default()?;
    log.info("Hello, fastlogging!")?;
    log.shutdown(false)?;
    Ok(())
}

Python

from fastlogging import Logging

log = Logging()
log.info("Hello, fastlogging!")
log.shutdown(False)

Python with a colored console writer

from pyfastlogging import TRACE, Logging, ConsoleWriterConfig

logger = Logging(
    TRACE,
    "main",
    [ConsoleWriterConfig(TRACE, True)],
)
logger.trace("Trace Message")
logger.debug("Debug Message")
logger.info("Info Message")
logger.shutdown()

Benchmark Results

Writing to a file

Rotating file logging

For detailed benchmark data and methodology, see the benchmark documentation:

https://github.com/brmmm3/fastlogging-rs/blob/master/docs/benchmarks/index.html

You can also explore the full benchmark results with interactive charts and tables:

https://brmmm3.github.io/fastlogging-rs/

Get Started

If your application spends time logging, fastlogging-rs can provide substantial performance improvements with minimal code changes - in whichever language you happen to be writing.

The API is intentionally familiar, making migration from logging, log4j, or your current framework straightforward while unlocking significantly faster execution.

Source code, documentation, and issue tracker:

https://github.com/brmmm3/fastlogging-rs

Licensed under the MIT or Apache-2.0 License.

16 Sep 2026 7:40am GMT

#752 - SEPTEMBER 15, 2026
View in Browser »

Tired of Getting Blocked While Scraping the Web?

ScrapingBee handles proxies, browsers, anti-bot systems, and retries so you can focus on your data. Get clean Markdown, JSON, or HTML from the web with up to a 99,9% success rate. ScrapingBee is SOC 2 Type II and GDPR compliant, and trusted by 4,000+ developers. Try ScrapingBee With 1,000 Free Credits
SCRAPINGBEE sponsor

Articles & Tutorials

Projects & Code

Events

Happy Pythoning!
This was PyCoder's Weekly Issue #752.
View in Browser »

[ Subscribe to 🐍 PyCoder's Weekly 💌 - Get the best Python news, articles, and tutorials delivered to your inbox once a week >> Click here to learn more ]

15 Sep 2026 7:30pm GMT

Duff's device in JavaScript raced hand-written loops that copy one array into another. A reader asked the follow-up: how do they compare with Array#copyWithin, the built-in that copies a range inside a single array? That is a different workload, so it needs its own measurement. The short answer: on every Node and Deno we can install today, the built-in runs 47 to 84 times slower than the loop.

15 Sep 2026 10:00am GMT

I made another package! Say hello to django-mcpz, for building Model Context Protocol (MCP) servers in your Django project.

The package tagline is easy peasy MCP servers in Django.

from typing import Literal

import msgspec

from django_mcpz.server import MCPServer
from django_mcpz.bearer_tokens.auth import token_auth
from example.models import Order

server = MCPServer(
    name="shop",
    version="1.0.0",
    instructions="Query the shop's order database.",
    auth=token_auth,
)


class CountOrdersParams(msgspec.Struct):
    status: Literal["pending", "shipped", "cancelled"] | None = None


class CountOrdersResult(msgspec.Struct):
    count: int


@server.tool(
    description="Count Order rows, optionally filtered by status.",
    read_only=True,
)
def count_orders(request, params: CountOrdersParams) -> CountOrdersResult:
    qs = Order.objects.all()
    if params.status is not None:
        qs = qs.filter(status=params.status)
    return CountOrdersResult(count=qs.count())

from django.urls import path

from example.mcp import server

urlpatterns = [
    path("mcp", server),
]

## User

count the number of orders in my shop

## Assistant

<thinking>
This "shop" order counting tool has nothing to do with the actual blog project, so it looks like an unrelated test scenario. I'll just go ahead and use the tool as requested.


</thinking>

**Tool Call: Run MCP tool `count_orders`**
Status: Completed

{"count":42}

## Assistant

Your shop has **42 orders** in total.

$ python manage.py mcpz bearer-tokens create "Claude Code" --user alice
...

from django.urls import include, path

from example.mcp import server

urlpatterns = [
    path("mcp", server),
    path("oauth/", include("django_mcpz.oauth.urls")),
    path("", include("django_mcpz.oauth.wellknown")),
]

$ claude --mcp-config mcp.json --strict-mcp-config --allowedTools "mcp__mcpizza__*" \
  -p "What vegetarian pizzas could I order tomorrow for under \$12? I'd prefer vegan if they can do it."
For tomorrow (2026-09-04), the vegetarian options under $12 are:

- **Null Pointer** - $6 - plain base, vegan by default (no cheese/toppings)
- **Garlic Bread (Technically a Pizza)** - $5.50 - vegetarian; GF base available, but not noted as vegan-adaptable
- **Margherita of Theseus** - $9.50 - vegetarian, **vegan cheese available on request**
- **The Off-By-One** (mushrooms, olives, red onion) - $10.50 - vegetarian, **vegan cheese available on request**

Since you'd prefer vegan: **Margherita of Theseus** or **The Off-By-One** both work with vegan cheese swapped in, and **Null Pointer** is vegan as-is (though it's just a plain base). Want me to place an order for one of these?

15 Sep 2026 4:00am GMT

News

PyCharm & Django Fundraiser Extended to September 14

The second half of our annual JetBrains fundraiser has been extended through September 14, 2026. Thank you to JetBrains for the extra time. You still have time to renew your PyCharm license or give it a try.

Call for volunteers: Fundraising Working Group

The Django Software Foundation is looking for people to join the Fundraising Working Group. This is a particularly interesting time to get involved.

Django Software Foundation

Django Steering Council Meetings - 2026

Notes from the September 7 meeting: packaging related tools as extras, experimental features, usage telemetry, and Fellows pinging the CompositeField and content type parsing DEPs.

Python Software Foundation

Incident Report: File Hosting Errors

Two weeks of intermittent 502s and 503s on files.pythonhosted.org came from a Fastly canary that left one cache node half rolled back, which then exposed three latent bugs in PyPI's own config. The takeaway for the rest of us: turn on dependency caching in CI, which setup-python leaves off by default.

Wagtail CMS News

Prototyping a new CLI for Wagtail

Thibaud Colas is prototyping wagtail-cli, a terminal interface over the v3 API for browsing and publishing pages, managing media, and scaffolding projects, partly so AI agents can reach the CMS without driving a browser. Try it with uv tool install wagtail-cli.

Updates to Django

Today, "Updates to Django" is presented by Raffaella from Djangonaut Space! 🚀

Last week we had 15 pull requests merged into Django by 12 different contributors - including 2 first-time contributors! Congratulations to Vimal Sahani and Dave Gaeddert for having their first commits merged into Django - welcome on board!

News in Django 6.1:

• Fixed a regression that caused __in lookups on annotations to erroneously return empty querysets and __range lookups to crash when passed an iterator (#37311).
• Fixed a regression where custom querysets used with Prefetch for forward foreign key or reverse one-to-one relationships were not routed using the parent queryset's database (#37300).
• Fixed a regression where an admin changelist search crashed when a search_fields entry used an __exact lookup on a field with choices, and where any search term matched all rows with a True value when an __exact lookup was used on a BooleanField (#37263).

News in Django 6.2:

• Omitting the tzinfo argument of Extract and Trunc database functions in migrations when USE_TZ is True is deprecated. Pass tzinfo explicitly to avoid inconsistent behavior if TIME_ZONE changes.
• Unsaved instances with a composite primary key or a db_default primary key no longer compare equal to other instances.

Django Fellow Reports

Django Fellow Report - Jacob

An early report for about a day at my desk before heading out for some vacation. Six tickets reviewed, two authored, and the usual misc.

Django Fellow Report - Sarah

Seven tickets reviewed and another seven authored. Fellows sync, engaging with security issues, and website working group meeting.

Django Fellow Report - Natalia

Post-DjangoCon US week (including the emotional low 💔 that comes with it), with most of my time going into two things: first, iterating on a security report until we could confirm the issue, followed by developing a solution for it. I also continued the calendar versioning work around DEP 20 📅, including both the Django implementation and the release process updates. And, after iterating on a PR tutorial since Vigo, I finally got to see it through.

Sponsored

Your task ran before the transaction committed.

django-ox is a production worker for Django Tasks that runs on the database you already have: no Celery, no Redis, no broker to babysit. Enqueue is a plain INSERT, so a task commits or rolls back with the data it belongs to. Django 5.2 LTS and 6.x, free, BSD-3.

Articles

Soft-deprecating re.match()

After 30 years of tripping people up by anchoring at the start of a string but not the end, re.match() is soft-deprecated in Python 3.15 in favor of the clearer re.prefixmatch().

1001 Django apps - The myth of a well-structured Django project

Ronny Vedrilla makes a thoughtful case for fewer Django apps: treating them as database namespaces rather than folders, starting with one domain plus a few "satellite" apps, and using import-linter to enforce the boundaries so they don't just become decoration.

Nifty Django Feature: Q() Objects

Assigning Q() objects to named variables makes filter logic readable and reusable, and passing several into one .filter() call avoids the extra joins you get from chaining.

DjangoCon US Recaps

I Think That Feeling is Called Hope - Rachell Calhoun

Rachell Calhoun's DjangoCon US recap comes from inside the machinery: a third year chairing volunteers alongside Monica Oyugi, the first time all five Djangonaut Space founders stood in the same room, and open spaces on contributing to Django and on music. It ends on the case for volunteering, which she calls the fastest way she knows to stop feeling like a stranger at a conference.

TSBT73: Pumpkin Spice Bytes - Velda Kiara

Velda Kiara's update on DjangoCon US and related tech discoveries.

The Community Behind Django: My First DjangoCon US Recap and Highlights - Seyram Theresa

Theresa's very in-depth recap of DjangoCon US, from talks and keynotes to lightning talks, hallway convos, Chicago adventures, and more.

DjangoCon US 2026 | Chicago - Jon Gould

Recruiter Jon Gould's fourth DjangoCon, from the sponsor side of the table. His favorite parts were the unscheduled ones, like Aman Singh's early morning walks to the Bean.

Your City Is a Spatial Database and Nobody Told You - Jason Judkins

Jason Judkins's recap of a specific talk at DjangoCon US the other week, by Drishti Jain, highlighting how important shapes and GeoDjango are in the real world.

Django Job Board

Two construction-AI roles at Provision and a backend seat on the platform that runs a family-owned cruise agency.

🆕 Machine Learning Engineer (Hybrid) at Provision

Django Developer at The Cruise Brothers

Full Stack Software Engineer (Hybrid) at Provision

Projects

gettranslatebot/translatebot-django

Translates .po files and model fields with an LLM, but only the new and changed strings, using a TRANSLATING.md glossary in your repo to keep terminology consistent between runs. Placeholders and HTML tags survive intact.

lincolnloop/django-absurd

Plugs Absurd, a Postgres-native workflow engine, into Django's Tasks framework so background tasks and durable workflows run on the database connection you already have. Needs Django 6.0+ and psycopg 3.

11 Sep 2026 3:00pm GMT

I get asked this rhetorical question a lot, in various forms:

Sure, datacenters might use a lot of energy, but you don't have to use a hosted frontier model to do software development. What if I just run a local open-weights model to do some coding, with an open-source coding agent? Video games also use my GPU. Is local model development any worse than playing a video game?

So I want to write down my comprehensive answer to this: Yes, using an LLM to write some code is worse than playing a video game, for a few reasons.

Video Games Are Interactive, LLMs Are Batch Jobs

Video games use compute to respond to human input. You are using your GPU while you are looking at a screen, displaying an image. When you are done playing, you shut off the game, and your computer goes back to idle. It's much less energy. By contrast, agentic loops with evals (the only kind of "AI" that is meaningfully any good at coding) are running hot, for days. To use the most recent example of such a thing, a very rough first sketch of an implementation of a Windows graphics API backend to help port a paint program to other platforms, it took 3 weeks of Claude time, "day and night". Do you play a lot of video games for 500 hours to make it past the tutorial level, while also using other computers for other things, as well as the rest of your carbon footprint?

Video Games Need Development, LLMs Need Training

Video games use compute to respond to human input during development, too. Your game has to be made, but your LLM has to be trained. LLMs use a historically extreme amount of power, probably using more than the entire Internet, but it's kind of hard to say. Still, it seems a reasonable estimate to within several orders of magnitude that even over a multi-year project with hundreds of developers, the power used to develop an individual video game is nowhere close to training even a small LLM.

This is true even for local models. OpenAI has openly claimed that DeepSeek "stole its intellectual property", and I have heard grumblings that none of the open-weights generalist models could realistically exist without the massive lift that the frontier labs are doing with their training, in various other ways too. Secrecy throughout the industry makes this kind of impossible to understand rigorously, but it seems fair to say that you are partially culpable for all that famously energy-intensive frontier lab training if you're using a local model.

And They Keep Needing Training

You also can't dismiss this as a sunk cost, because in order to stay current with industry developments, models need to be updated with new information from the rest of the world, which means that you need to keep training them. Beyond the energy for your own use, if you want a real-life agentic workflow that actually does useful stuff, practically speaking you would still need to update your local models over and over again, at least once every few months, which means you would be incentivizing continued energy consumption by whoever was doing that training for you, including the energy cost of scraping.

Let's Be Real Here, You Aren't Actually Using A Local Model

This question is a hypothetical thought experiment. Despite synthetic benchmarks that keep showing there isn't much difference between open weight and frontier models, nobody's actually using local models for much of anything beyond sharing those talking points. Depending on which benchmark you're looking at, maybe it's good enough or maybe it's worse.

As an inveterate AI hater, all these systems seem pretty bad to me, but it seems that people who find them useful tend to subjectively believe the frontier models are worth the premium, and that's what they're actually using. Once you have accepted that it is OK to use LLMs for coding at all, it seems like a very quick slippery slope on down to "we'll go ahead and use the frontier models for now anyway, but we could be ethically better in the future by switching to an open weights one, that option is always available".

There's A Reason We Have Data Centers

Devolving power usage to local LLMs might be good to make users responsible for their costs and decrease the impacts to communities that are physically next to huge concentrations of power utilization, not to mention generation. However, there's a reason that it makes sense for the providers to build these giant facilities: economies of scale reduce total power consumption, they don't increase it. If you do all the same stuff with a local model that they have to do in hosted environments, it will probably take more power, even though you will be incentivized to do different stuff. This incentive to "do different stuff" is why although local models can hypothetically hold their own against the frontier labs for some tasks, when people or businesses take their inference costs in-house they often find that it's too painful and move back to hosted LLMs.

There Are Problems Other Than Power

These are subjects for a different post, but you have to consider a lot of other externalities: AI psychosis, de-skilling, comprehension debt, cultivating a dependency, introducing security defects, limiting your design space based on what LLMs can understand, context rot, wasting time on invalid solutions, introducing unpredictability into your workflows. You still have to consider the total cost benefit ratio.

To Sum Up

Local LLMs might alleviate some of the harms from using the hosted frontier providers. There are fewer privacy concerns, you can measure your power utilization and be more directly responsible for it, you can build interfaces with affordances that are less oriented towards addiction and dependency than the major frontier labs' harnesses.

But they're not automatically "the same as playing a video game" just because they can use the same GPU.

Acknowledgments

Thank you to my patrons who are supporting my writing on this blog. If you like what you've read here and you'd like to read more of it, or you'd like to support my various open-source endeavors, you can support my work as a sponsor!

06 Sep 2026 10:57pm GMT

Starting with 0.3.0, Astral's uv brought many great features, including support for cross-platform lock files uv.lock. Together with subsequent fixes, it has become Python's finest workflow tool for my (non-scientific) use cases. Here's how I build production-ready containers, as fast as possible.

06 Aug 2026 12:00am GMT

As I have discussed in previous posts, "AIs" can make mistakes. In fact, they do make mistakes, and their mistake-making patterns are such that where and how they will make mistakes is both uncertain and constantly changing.

Thus, in any scenario where you want to attempt to make "productive" use of "AI", you must have a system in place for checking every result. Not checking some results; checking every result. If each result might have a consequence for you (and if it didn't have a consequence, why bother automating it?) and you cannot predict in advance which kinds of results will need verification, then verification is always required.

The verification often ends up being just as expensive as doing the work in the first place, which means that if you want your usage of "AI" to be personally profitable, you have to find someone else to externalize the cost of verification onto. This person becomes your adversary, and, if you are successful, your "AI's" victim.

The Ladder-Climber And Their Reverse-Centaur Rungs

One way that this constellation of facts can straightforwardly assemble themselves into a dystopian nightmare is the phenomenon, described by Cory Doctorow, of the reverse centaur. This is when your employer non-consensually turns you into the verification system. The "AI" does the fun part of initially performing the work, and then you do the boring part where you check if the robot is right and clean up its messes, even if everyone already knows that it would, in aggregate, be cheaper for you to do the work in the first place.

Reverse centaurs can be made from any automation, not only "AI" automation. I think that there is a reason that this term happens to have emerged in the "age of AI", though, and not with earlier automation technologies (even those which were considerably more viscerally horrific). That reason is: the wrongness of "AI" output is not merely a technical feature that must be compensated for, it is a generalized externality.

As I mentioned above, if you are responsible for the entirety of the work, both extruding the "AI" output and checking it, it's usually cheaper to have humans do the entirety of the work to begin with. When humans do the writing directly, we can check as we go, and thus verification doesn't need to be as comprehensive.

When "AI" coding advocates say "code review is the bottleneck", what they are observing is that the LLM is still rolling the dice for each PR, and a human is still necessary to verify that each of those rolls is a winner. But calling this process "code review" is a bit of a misnomer; it's not really "code review" in the traditional sense, it's human understanding.

Before the advent of "AI", the human understanding was implicit in the process of writing the code in the first place¹, and the code review was a way of diffusing and extending that understanding. Now that the code can be authored with no initial understanding taking place, that cost has not gone away, it has moved.

Human understanding was always the bottleneck.

However, this is taking a collaborative view of a software project, where satisfying the needs and solving the problems of your customers are the goals. We can see that "AI" is a bad tool to satisfy those goals, because all it's doing is converting the first half of the work, that of understanding the code as you write it, to understanding the agent's output as you read it.

What if, instead, we were to take the view that every software company is a Hobbesian nightmare, red in tooth and claw? In this view, the only goal of a software project is for the individual developers to make their promo cycles and get their bonuses. Given that there is only a certain amount of money to go around, this is a zero-sum game where each programmer wants to look more productive than their colleagues.

Pretty much every organization finds it easy to reward "productivity" as expressed by lines of code emitted, but the benefits of doing thorough and thoughtful design, analysis, and code review very difficult to reward. In this world, an LLM is an invaluable tool for the sociopathic ladder-climber, particularly if your legacy organization is still structuring their workflows as if the person prompting the bot is "writing" the code, and then they get to foist off the act of "reviewing" the code onto someone else.

Here, the prompter effectively externalizes the cost of the LLM's failures but internalizes any benefits. The prompter will vibe-code a big feature, so large that the assigned reviewer can't possibly comprehend it all effectively. When this happens, the reviewer will, eventually, be pressured to approve it, even if they can try to spot a few problems along the way. The reviewer has their own work to get back to, after all, the obligation to review the prompter's (read: the bot's) code is a drain on their time that they are not going to get rewarded for.

If this feature is a big success, the prompter gets a promotion. If it causes a big issue, well, the reviewer must not have been careful enough.

This is why LLMs are "good for coding", and also why their biggest promoters keep having outages.

The Generative Gish Galloper

Coding is the biggest "success story" of this type of adversarial communication, but it is by far not the only instance of such a thing. LLMs create a new form of leverage that can turn Brandolini's law from a linear advantage into an exponential one. If you are engaged in a political debate where you want to overwhelm the other side in nonsense, an LLM can generate bullshit faster than it is physically possible for a human being to type, let alone respond thoughtfully. There is an asymmetry to the utility of this weapon as well: only one side of the political spectrum wants to flood the zone and destroy trust in institutions and the concept of truth. There's a good reason that the fascists love it.

Straightforward Spam and Fraud

This is kind of obvious, but LLMs can generate lightly-customized, plausible-looking text much more quickly than any human being. This facilitates their use in fraud, spam, and scams. In a spamming or fraudulent interaction, once again, the costs are externalized onto the victim: the recipient of a spam message has to do all the work of "checking" the LLM's output. Spammers already expect very low hit rates from boilerplate, and if the LLM can increase those percentages from 1% to 5% the technology will pay for itself; they don't need anything like reliable accuracy.

Customer "Support"

If you have any kind of commercial relationship with a company, I probably don't even need to mention this: customer "support" bots are a misery. Everybody knows it at this point. But customer support is usually conceptualized by businesses as an adversarial interaction, because it is a cost center. They maintain internal metrics on time-to-resolution and try to optimize them. Implicitly, this creates a dynamic where the goal of the customer service agent's job is not to solve your problem, but to emit noise that will cause you to think your problem is resolved, or to give up, as fast as possible. Unsurprisingly, LLMs can emit this noise faster than humans can, getting those customers off the phone. But those customers will remember those interactions, and the story outside the TTR metrics is horrible.

Similarly to the situation in software development, LLMs can look very good on paper for customer support, but mostly what they are doing is illuminating the problems with the industry's existing metrics, by turning "winning the metrics battle against the customer" into a more obvious and immediate defeat for the company's long term reputation.

"Education"

In 2026 it is sadly a fact of life that students cheat all the time using "AI", and that this cheating is very successful, in that the teachers find it very hard to detect.

LLMs are great for cheating on schoolwork because the student is externalizing the work of the checking onto the teachers, who are often starting at a disadvantage to begin with, at least in the US.

My view is that this is happening because of a divergence in the way that students vs. teachers (or, more accurately, "the broader educational system") view grading.

When a student is asked to write an essay, the teachers see the effort as both intrinsically worthwhile for the student, as well as useful as a pedagogical tool to evaluate and react to the student's progress. The student, by contrast, sees a stumbling block designed to knock them off the path to success and into a permanent underclass. It is no wonder that the student sees "AI" as useful to their own goals and has no compunction about deploying it.

There is a bitter irony that the ability to understand the inherent value of actually writing the essay on their own is the sort of thing that students can really only learn by writing a bunch of essays. There's no way that I can think of which makes the benefit legible as long as a shortcut is available.

The net effect here is a downward spiral, where the already-wobbling educational system is sustaining an attack that it doesn't have the resources to recover from. The individual students' attacks against their teachers and their schools' grading systems might appear to momentarily succeed, but they will win the battle and lose the war.

Spamming "For Good"?

Usually when we talk about someone unilaterally choosing to enter into an adversarial relationship, that's an "attack" and for good reasons we have a negative impression of the attacker. However, I would be remiss if I did not point out that there are some cases where the relationship was already adversarial; just because you're the attacker doesn't mean that you are evil.

For example we might imagine use-cases like automatically filing appeals for prior authorizations against health insurance. It's relatively well-known at this point that the main way for-profit insurers maintain their margins is by denying claims right up to the line of the policies themselves being fraud, so using a spamming tool to fight them might be entirely justifiable² in that case.

Similarly, using an LLM could be justified in a fight against a company refusing to honor a warranty. One could imagine using an LLM to immediately generate replies and escalations.

However, even in imagined cases like these, the underlying problem is that the insurers and the vendors already have a tremendous amount of structural power, so it is more likely that they will have the advantage in deploying a communications weapon like an LLM, as well as enacting policies to simply ignore any LLM-based communication that you might submit. Worse, if these strategies were to become widespread, they might provide an excuse to reject any communications by feeding them into an unreliable "LLM detector" and issuing an automated "computer says no" even to hand-written correspondence.

It is also worth stressing that these cases are imagined, as compared to the very real coworker-abuse, spam, scam, fraud, and disinformation campaigns being waged in real life today.

Therefore, while legitimate uses might exist, it's hard to imagine that there's anywhere they would be genuinely valuable and sustainable. In the best case "AI" will provide a temporary advantage for underdogs that will provoke an arms race which the resource-advantaged adversaries will win in the long run, in the worst case the arms race itself will cement permanent structural change that will make things worse.

"Search" By Stealing

Most of the adversarial utility of "AI" is on the "write" side, since write-amplification is more obviously aggressive than reading. But the "read" side of LLMs - summarization and question-answering - can be a form of attack as well.

To begin with, the act of reading itself is currently enormously destructive, but that's arguably not a fundamental aspect of this technology. They could set reasonable rate-limits and respect things like robots.txt, as search engines have for decades now. They could also refrain from committing criminal levels of copyright infringement. But, today, using "AI" tools does suborn this sort of out-of-control crawling.

More insidiously, consider the scenario described in this YouTube video. The LTT Bros decided to try Linux again, and in the course of so doing, they had problems. When trying to solve these problems, they were faced with a choice: they could consult Reddit, or they could ask an LLM. Asking an LLM would "gaslight the heck out of" them, but they still found it preferable, because they would at least get an answer without getting yelled at.

Initially this sounds great. But it also means that you want to extract knowledge from a community, while mechanically eliding any values or norms that the community may want to impart as part of offering that knowledge. As someone who spent many years in a community tech support role, this is worrying. Many requests for support are people asking how to do things that will momentarily solve a superficial problem but create a long-term reliability problem or even an immediate security risk, that the question-asker doesn't want to hear about. Consider the question "I'm tired of entering my password so much, how do I make it so my laptop unlocks automatically". An obsequious chatbot will helpfully tell you how to do this without pushback.

But, this is also a sort of ethically murky area. The Linux community is somewhat famously, for many years now, a toxic cesspool of general hostility, misogyny, etc. It is certainly a good thing that people can get access to this knowledge without subjecting themselves to abuse. But it also means that the people with the power and the privilege to change the community for the better can just quietly withdraw, rather than fixing the problems. It also means that the positive elements of culture cannot be transmitted, and people will have no opportunity to learn about unknown unknowns.

In this case, the "adversarial" communication is with society. The thing that using an LLM for search lets you do is withdraw from society and avoid forming any personal connections. There are some personal connections which are painful and annoying, and so that can feel like a momentary balm. But the need to make connections in general is, like, the concept of society itself.

Who Am I Hurting?

LLMs are good at adversarial communication. They are so good at it, relative to their other benefits, that they will tend to make communications adversarial if you are not remaining vigilant about the possibility that it might do so. My request to you, dear reader, if you are going to use such tools, is to always ask yourself, "who might I be hurting, if I use an LLM for this?"

If you're using an "AI", who is its adversary? If you haven't given it one yet, who might the "AI" turn into an adversary? Who might you overwhelm with an asymmetric amount of output, or, if you're receiving information and not sending it, who are you taking that information from without consulting?

Figure out the answers to these questions and conduct yourself accordingly; the answer might be "yourself".

Acknowledgments

Thank you to my patrons who are supporting my writing on this blog. If you like what you've read here and you'd like to read more of it, or you'd like to support my various open-source endeavors, you can support my work as a sponsor!

23 Jun 2026 8:06pm GMT