fidzu : python

We'll see you in Chicago! Jeff and Will are heading to DjangoCon US next week, so if you're going too, come say hi.

News

Almost Time: What to Know Before You Head to Chicago

DjangoCon US 2026 kicks off Monday, August 24 in Chicago, with registration and breakfast starting at 7:30 AM on the 14th floor. Watch for Friday's attendee email with your Slack invite and lightning-talk sign-up, and if you're sticking around for sprints on August 27-28, grab a free sprints ticket now.

New One-Day and Online Tickets

Can't make the whole week? DjangoCon US 2026 added one-day in-person tickets that also include online access to every other session, plus online-only tickets for remote attendees.

DSF Membership Open Space at DjangoCon US

Bring your questions about the Foundation to DSF board directors on Wednesday, August 26, 1:00 to 1:45 PM in the Wolf Point Ballroom.

Djangonaut Space News

Session 7 is preparing to take flight 💫

Session 7 runs October 12 through December 6, with teams of three or four Djangonauts guided by a Navigator and a Captain, working on Django Core, django CMS, Django Debug Toolbar, the Django Girls+ website, BeeWare, and Render Engine. Plan on about five hours a week, and note that past sessions have accepted roughly 10% of applicants, so fill out every section. Applications close September 6, 2026, Anywhere on Earth.

Updates to Django

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

Last week we had 13 pull requests merged into Django by 6 different contributors - including 2 first-time contributors! Congratulations to Karan Suthar and Jens Spanier for having their first commits merged into Django - welcome on board!

News in Django 6.1:

• fetch_mode=None is added to the signature of from_db().
• It's fixed a regression where the deprecation of double-dot variable lookups incorrectly applied to string and translated template literals containing two consecutive dots, such as a..b (#37257).
• Fixed a regression where ModelAdmin.list_display entries that traverse multiple relations using __ could crash or display incorrect values (#37270).
• Fixed a regression that caused AlterField operations that changed only the Python-level on_delete option of ForeignKey or OneToOneField fields to perform unnecessary schema changes (#37260).

Django Fellow Reports

Django Fellow Report - Jacob

Jacob Tyler Walls spent the week sweeping up after the 6.1 release, triaging admin changelist search crashes on __exact lookups, a Model.from_db() override crash, and unnecessary DDL when only a Python-level on_delete changes. He also accepted tickets for calver support in django.utils.version and for updating the release process docs under DEP 20, while GIS, caching, and the GSoC multi-column subquery work continued.

Django Fellow Report - Sarah

Sarah Boyce worked through Django 6.1 release blockers: an admin crash when ModelAdmin.get_action() is overridden with its pre-6.1 signature, values() querysets crashing on models with Meta.ordering, DecimalField without precision on SQLite, and second-degree relations in ModelAdmin.list_display looking up values on the wrong model. She also documented the YYYY[.N] versioning scheme and updated the download page for the newly approved annual release cycle.

Sponsored

Simple APM dashboards for Python. Set up in just 5 minutes

Drowning in data? Honeybadger gives you Just Enough APM™ without enterprise bloat or cost.

Our dev-friendly APM dashboards expose metrics and trends across your apps and infrastructure, so you can find and fix Python issues before users notice!

Articles

Nifty Django Feature: Counting on Multiple Columns

Count only counts one column at a time, so counting unique pet-and-vet pairs returns either every appointment or every distinct vet, never the answer you wanted. The fix is a small Subquery subclass whose template wraps values("pet", "vet").distinct() in a SELECT COUNT(*), which is a nice demonstration of how far Django's expression system bends.

django-upgrade 1.32.0 out now, with 44 AI-assisted bug fixes

Adam Johnson turned Claude loose on django-upgrade with the prompt "Find and fix bugs" and shipped 44 fixes across two rounds. The catches include url() to path() conversions that mangled regexes with literal angle brackets or unescaped dots, a five-year-old fixer that rewrote calls to html.escape() when it meant html.unescape(), and a multi_db = False mapping that produced an empty database list and blocked every query in a test.

Nearly 20 years of choosing Django

Lincoln Loop has attended or sponsored most DjangoCons since the first one in California in 2008, where founder Peter Baumgartner gave an early lightning talk. The team credits the conference with teaching them how to work a booth, order swag people actually wear, talk to strangers, and, for several of them, get over a fear of public speaking.

Docker Compose reads .env files by default

Compose reads the .env file in the directory you run it from and honors any COMPOSE_* variables it finds there, which is easy to miss if you think of .env as something that only reaches your containers. Frank Wiles uses it to set COMPOSE_FILE=compose.yml:overlay-compose.yml per directory, so a worktree can remap ports and add labels without touching the shared compose file.

Events

Start DjangoCon US at the Welcome Reception

Kick off the conference Sunday, August 23, 7-9 PM in the 15th Floor Lobby, with casual conversation and drinks courtesy of REVSYS, Two Rock Software, and Caktus Group.

Sign up for Travel Safety Checks & Chicago Travel Safety Updates

Traveling to Chicago from out of town or abroad? Sign up for the optional Travel Safety Check so someone can check in with you by WhatsApp or Signal once you've arrived.

Introducing Open Spaces! (And Why You Should Host One)

Pitch a topic on a sticky note and host your own participant-led discussion during Monday and Tuesday's Open Spaces sessions in the Wolf Point Ballroom.

DjangoCon US

TIME RUNNING OUT! 10% off

Join us in Chicago or ONLINE! August 24-26 for the main conference, followed by two days of sprints. Online and one day tickets also available.

Videos

Interview with Django Expert Paolo Melchiorre on AI and Open Source

DSF Board Member Paolo Melchiorre talks about Django, AI-assisted development, open-source maintainership, and how the Python community is adapting to AI.

Why AI Coding Agents Fail on Real Codebases - Sheena O'Connell on Spec-Driven Development

PSF director and Django developer Sheena O'Connell sat down at PyCon US to discuss spec-driven development, AI agents, and why so many teams struggle to make agentic coding work in practice.

Django Job Board

Full Stack Software Engineer (Hybrid) at Provision

Toronto-based construction-AI startup building full-stack product surfaces and AI-forward document-processing systems.

Executive Director at Django Software Foundation

Remote US role running the DSF's fundraising, operations, and public representation as its first Executive Director.

Security Developer at Python Software Foundation

Global remote role triaging CPython/PyPI vulnerabilities and remediating supply-chain attacks alongside the Python Security Response Team.

Senior Full Stack Engineer at Hive Collective

US-only remote, backend-leaning full-stack role at a profitable LegalTech SaaS with an AI-assisted workflow.

Senior Backend Engineer at MyOme

Remote US backend role building portal integrations for patients and providers ordering genetic testing.

Python + TypeScript Engineers at Fusionbox

Remote US consultancy role building Django/React systems for financial workflows and multi-tenant architectures.

Projects

alzeph/django-forge-log

A lightweight, automatic audit trail - Who, What, When, Where, and the before/after Diff - for Django views (FBV, CBV, DRF ViewSets) and the Admin, stored in a single central JSON table.

tim-schilling/django-salmon

Does the monkey-patching of Django's internals once, then exposes a standardized set of signals so APM and observability tools do not each have to reinvent it. Receivers get args, result, timing, and a lazy stacktrace, and the decorator stack per facet is configurable.

21 Aug 2026 3:00pm GMT

If you are at DjangoCon US this year, join us for 45 minutes to talk about the Django Software Foundation.

• What: Django Software Foundation Membership Open Space
• When: Wednesday, August 26th, 1:00 pm to 1:45 pm
• Where: Wolf Point Ballroom, voco Chicago Downtown
• Schedule: Talks: Wednesday, Aug 26

DSF Board Directors Jeff Triplett, Abigail Afi Gbadago, and Paolo Melchiorre will be there, along with Django Fellows, Steering Council members, and other DSF members. This is an open space, not a talk. Pull up a chair and bring your questions.

What We Want to Talk About

• Fundraising and finances. We raised our 2026 goal to $500,000. We'll cover what it funds, most of it the Django Fellows, and how we are tracking against it. If your company depends on Django, or you know one that does, ask us about corporate membership and sponsorship.
• The Executive Director search. The DSF is hiring its first Executive Director, and applications are open through midnight Central Time on September 14, 2026. If you are thinking about applying, or know someone who should, ask us about the role.
• Membership. How individual membership works, how people become members, and what members do. Members vote in DSF elections, and we would like more of you to.
• Working groups and teams. You don't need to be a DSF member to join a working group, and we could use your help. Teams work a little differently, and we can explain the difference.
• The Steering Council. A short update on DEP 19, which rewrites Django's technical governance, and DEP 20, which moves Django to one feature release a year.

This is your time as much as ours. If you have a question about how the Foundation spends its money, how decisions get made, or why something is the way it is, ask it. We would rather answer a hard question in a room in Chicago than in a thread three weeks from now.

One note on scope: this session is about the Foundation, not about code. We will touch on the DEPs above, but patches, ORM internals, and your favorite ticket belong to the rest of the week.

Who Should Come

Everyone. You do not have to be a DSF member to attend: no sign-in sheet and no membership check at the door.

If you are already an Individual Member, meet the others. If you have been curious about joining, see what you would be joining. And if you use Django at work but have never thought much about the Foundation behind it, that is a fine reason to stop by.

Can't Make It?

Send anything you want raised through the Contact the DSF page, or find us on the Django Forum. We will follow up on anything worth sharing more widely.

See you Wednesday.

21 Aug 2026 2:11am GMT

Optimize Images X, the multi-platform desktop application that helps you reduce the file size of your images on macOS, Windows and Linux, has just been updated to version 2.2.0. This new version adds full internationalization support with some initial translations, plus a handful of minor UI adjustments.

20 Aug 2026 10:50pm GMT

Written by Jacob Coffee, Director of Engineering at the Python Software Foundation

Working on infrastructure at the Python Software Foundation (PSF) as the Director of Engineering is a broad job with many hats. Python turns up everywhere. It's in healthcare systems and government agencies, in research labs and classrooms, in one-person side projects and in infrastructure at companies with six-figure headcounts. Somebody is using it to analyze a genome right now and somebody else is using it to automate a spreadsheet they hate arranging by hand. That range has always been the interesting part of the PSF's work, and it's only broadened in the last couple of years as AI continues to pull people from many disciplines into writing Python.

At the PSF we support and maintain the infrastructure behind PyPI, Python.org, PyCon US, CPython, and a growing number of community services. The majority of the PSF's infrastructure runs on AWS, and nearly all of that bill is covered by credits from the AWS Open Source Credits Program.

The shape of it

PyPI takes over six billion requests a day and about thirteen billion counting file downloads. Package egress runs around 10 petabytes a day.

Almost none of that reaches AWS. Fastly serves it at the edge through their Fast Forward program at a hit ratio just under 99%, so only about one request in seventy makes it to origin. That caching is the core reason our AWS bill is not measured in the millions of dollars a year.

What does reach us is the part that is not cached, including things like user uploads, logins, and account management. That work runs on:

• Amazon EC2 for the application fleet, almost entirely Graviton at this point. We're huge fans of Arm-based hardware at the PSF!
• Amazon RDS for the Postgres database behind Warehouse, which is the application you're looking at when you're on pypi.org.
• Amazon OpenSearch Service for project search.
• Amazon S3 holds ~100 TB of package archives, plus the release history (that nobody ever wants to need).
• Amazon EKS, newly stood up, as the target for migrating the whole fleet.

What changed this year

Our AWS spend is up about 69% comparing July 2026 to July 2025, and 40% across the trailing twelve months. That's new.

For context on how new: last October, Ee Durbin, our former Director of Infrastructure, noted that PSF's AWS credit usage had grown 25% over eight years while daily requests went from millions to billions. Eight years of holding that line. 2026 is the first year it broke.

Some of it is simply more of everything. Compute, search, and load balancing all climbed from 30% to 80%, which is the profile of more people and machines using the service. There are certainly more of both. A lot more Python being written, a lot more agents installing packages on someone's behalf, and a lot more CI runs from all the projects those people and agents are creating. Package repositories were designed around the assumption that a human decides to run pip install some number of times a day. That assumption is well past its expiration.

What we do about it

At the PSF, we take the credits seriously, which means spending real engineering time on utilizing what we have in an optimal way so our usage doesn't increase. Being frugal with the credits entrusted to us is vital.

When a widely used GitHub Action makes requests it doesn't need to make, fixing the Action beats anything we can do on our side. A popular Action can quietly turn a cache hit into a fresh download from PyPI on every run, and that adds up fast across thousands of CI pipelines. astral-sh/setup-uv shipped exactly that kind of fix.

On the PSF side, the EKS migration is the big one. Once we're there, autoscaling lets capacity track demand instead of sitting provisioned for peak at 3 AM (San Francisco time) on a Sunday.

There's just one little (read: major) constraint: Ee left the PSF earlier this year, and I'm currently the only person here working full time on infrastructure. Every item on that list is real and every one is slower than it should be. The PSF is hiring, and that hiring is possible in part because we aren't spending the same money on servers.

That said, hiring has a ceiling set by funding, and the growing gap between the demand placed on PyPI relative to staff operating and securing the service represents a risk to Python packaging. There is a very large amount of the software industry that sits on top of our services. Feature development, a rising volume of security reports, and day to day maintenance are currently being carried by one and a half full-time employees and one full-time employee on PyPI support requests. If your company installs from PyPI, ask internally about what your organization would be willing to fund. That question can be worth much more coming from inside a company than from the PSF. If you are interested in securing a service agreement with PyPI, please fill out our survey.

What the funding actually bought

AWS has backed PyPI two different ways, and both are worth outlining.

A very exciting investment was made in 2023, when AWS became PyPI's inaugural Security Sponsor, putting $144,000 into creating the PyPI Safety & Security Engineer role. That role is now funded by Alpha-Omega, and it's the reason malware comes down off PyPI in hours instead of whenever a volunteer has a spare moment. This investment also followed a pattern AWS had already established, having helped fund the rewrite, internationalization, and 2FA support for PyPI.

The credits do something quieter. They hold the infrastructure bill near zero, which means the PSF's general fund goes to employees, PyCon US, and other operational costs instead of servers. That's what pays for support staff handling the account recovery and project ownership requests that arrive every single day, and what makes it possible to ship things like Trusted Publishing, digital attestations, and organization accounts, instead of just keeping the lights on.

PyPI is free to use and will stay free to use at reasonable levels. Core publishing and installing stay free, permanently. What we are doing is building out real benefits for Organization accounts, and looking at sensible rate limits for the heaviest consumers at the top of the curve.

Which is exactly why in-kind support isn't just a line item to us. A sponsor choosing not to renew would mean an emergency migration or tens of thousands of dollars a month, either of which comes straight out of the work above. AWS has renewed every year since 2018, and the predictability of that is worth as much as the amount. The same goes for Fastly, Google Cloud, Datadog, Sentry, Depot, and PagerDuty, who carry other parts of this mountain of infrastructure.

How you can help

Four things, in order of how much they matter:

1. Cache your installs. If your CI pulls from PyPI on every run with a cold cache, you're a meaningful part of the graph. The PSF uses Docker cache mounts and pip's cache on our own builds, and npm and apt caching too, because it's faster for us and cheaper for everyone. Free package repositories aren't a limitless resource, and the fix is usually about six lines of config.
2. Sign up for a PyPI Organization if your company publishes to PyPI. Recurring revenue from Organizations is the most sustainable funding base we have, and Community organizations remain free. Look forward to announcements about future features for PyPI organization accounts soon.
3. Interested in a PyPI service agreement? Enhanced options like annual bulk seat purchases, higher project size limits, and prioritized support are available. The revenue helps fund the broader PyPI ecosystem while giving your organization benefits at scale. Fill out our service agreement interest survey and we'll follow up.
4. Ask your infrastructure vendors for multi-year commitments with open source foundations. Annual renewal cycles carry real risk for projects like ours. The five-year agreement the PSF signed with Fastly in 2024 is a sustainable model, and we'd like more of them.

The open letter the PSF co-signed last year called this a critical inflection point rather than a crisis. A year on, with our first real break in eight years of flat infrastructure costs, that still reads about right.

A big thanks to Mila Zhou and the AWS Open Source team, who have made the credits process about as painless as an annual funding renewal can be, and to everyone at AWS who's kept this program going for so long. PyPI would look very different without it.

This blog was recently edited to more accurately reflect numbers presented and work done.

20 Aug 2026 4:10pm GMT

The last post argued that break, continue, and labeled jumps are structured goto - disciplined jumps that keep code linear. Two ordinary language features are jumps in disguise: yield, which suspends a function and later resumes it in the middle, and throw, which leaps across stack frames to a waiting handler.

18 Aug 2026 10:00am GMT

django-upgrade is my tool for automatically upgrading your project code for new Django versions. It rewrites your Python files to fix deprecations and adopt some new features, taking a chunk of the monotony out of upgrading between Django versions.

Yesterday, I released version 1.32.0, which fixes 44 bugs. Some are big, some are small, and all of them were found by Claude Fable, with this simple prompt:

Find and fix bugs

Yup, that's it. Across two rounds of self-directed bug discovery, Claude found and fixed these bugs, matching the coding style and changelog entries. It needed one more prompt to split the fixes into individual commits.

I am pretty astounded at how well this little project worked. Claude worked "in the cloud", while I was doing other stuff, so the bottlenecks to progress were my review capacity and CI runs on GitHub Actions for each commit.

My big takeaway is that given such LLM power, the bar for software quality should be raised.

Let's review some of the bugs that it fixed, within the individual code fixers in django-upgrade.

-    url(r"^go/<page>/$", views.redirect_angle),
+    path("go/<page>/", views.redirect_angle),

-    url(r"^report.pdf$", views.report),
+    path("report.pdf", views.report),

-from django.utils.text import unescape_entities
+import html

-text = unescape_entities(raw)
+text = html.escape(raw)

>>> html.unescape("Tom & Jerry")
'Tom & Jerry'
>>> html.escape("Tom & Jerry")
'Tom & Jerry'

 class OrderTests(TestCase):
-    multi_db = False
+    databases = []

 class OrderTests(TestCase):
-    multi_db = False
+    databases = ["default"]

18 Aug 2026 4:00am 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

Codecov's unreliability breaking CI on my open source projects has been a constant source of frustration for me for years. I have found a way to enforce coverage over a whole GitHub Actions build matrix that doesn't rely on third-party services.

09 Jun 2026 12:00am GMT