I'm running a workshop in Lisbon next month, and you're invited!

It's a small, in-person, hands-on session on optimizing Python code, with a Django flavour. Here are the details:

• What: Python optimization workshop
• When: Saturday 10th October 2026, 10:00-13:00
• Where: Martinhal Lisbon Oriente, Parque das Nações, Lisbon.
• Cost: Free, but places are limited and registration is required
• Size: Up to 10 people
• Led by: Myself, Adam Johnson
• Organised by: Mafalda Marques

Register on Luma

19 Sep 2026 4:00am GMT

I keep hearing this a lot: the Python syntax I picked up in an afternoon, but shipping a real project meant learning ten more things. There is a stark difference between writing some code in Python vs building an app that someone else can run on their system. These skills are taught, but rarely together in one place. So I am building a free course to teach this.

The gap I want to help close

I spotted a post on r/learnpython recently of someone who had done several courses, worked with pandas, NumPy, and scikit-learn, and understood the language well, but had never learned the complete development cycle. The confusion:

• Installing Python
• Using the terminal
• Installing packages with pip
• Virtual environments
• Choosing/configuring the correct Python interpreter
• Organizing a project
• Saving and reusing dependencies
• Running and debugging code
• Git and GitHub
• Understanding how to share a project with someone else
• Understanding what I actually need to install versus what belongs inside my project

And the framing was spot on:

I'm not looking for another beginner Python programming course. [...] What I need is something that teaches me how to actually work as a Python developer on my own computer.

None of that is Python the language. It's the workflows around it, and it is genuinely the harder part to learn, because a. it's often skipped over or set up for you, and b. it's a lot of moving parts touching adjacent domains: the OS, the shell, the editor, the package manager, and git / GitHub.

You can learn Python without ever learning any of that (e.g. using it in a notebook), but building a real shared project without these skills is not possible.

Fortunately things timed well. One of the developers I'm currently coaching started mentoring beginners at her company, and she confirmed this gap: getting Python and package management working locally is where a lot of people still get stuck, often before they write a single line of code.

The course: 6 weeks, one small app

So I'm building Ship Your First Python App, a 6-week course that teaches the local development workflow from scratch by building a small command-line app: a dev journal.

The first week is live, and every Friday a new week is released. The course is free, self-paced, and right here on this site. You can start it right now.

This is the course that person on Reddit was looking for.

Here is what you'll learn each week:

• Week 1) Project Setup & Data Model (live now): the terminal, Git, SSH keys and your first pull request, starting a project with uv, and modeling data with a dataclass serialized to JSON.
• Week 2) CLI & Type Safety (Sep 25): wrap it in a real command-line interface using the Typer library, add type hints, and handle errors so users get a clean message instead of a traceback.
• Week 3) Features & Search (Oct 2): case-insensitive search, tag filtering, and limiting to only see the most recent entries.
• Week 4) Code Organization & Testing (Oct 9): split one file into modules, making a proper package, group persistence into a class, and share test setup with pytest fixtures.
• Week 5) Test Coverage & Polish (Oct 16): using the Rich library to nicely format an output table, and measuring coverage with pytest-cov to find untested code.
• Week 6) Ship It (Oct 23): write a README, do the final verification pass, merge, and optionally publish the package to PyPI or add a (web) frontend.

Each week you're handed a failing test suite and write the code to make it pass, so you are always coding against a clear spec and reading real pytest along the way. You also make a new branch and open a pull request each week, so you practice the full cycle of a real project. This mirrors how I work in my Snipster, Rust and Agentic AI cohort programs.

Who it is for + feedback appreciated

You can read and understand basic Python code, but you struggle with all the pieces around it required to ship an app. Or you've done that but you want a refresher on the newer tooling like uv and ruff. You have scripted in Python but want to ship a small project end-to-end using the proper workflows.

You do not need prior experience with CLIs, packaging, or git. That's what this course will teach. I hope you're excited to dive in and learn this critical piece of Python software development with me. You'll see the weeks unlock as we go. It's very important to me to get feedback to make this as useful, practical and pleasant as possible.

Don't hesitate to hit me up on X, LinkedIn or email me with your thoughts.

Have fun and learn a lot! 🚀

19 Sep 2026 12:00am GMT

We're proposing a new voting membership status to help us track active members. If you've voted in a Board election in the last two years, you're active, and you count toward quorum. If you haven't, you're still a member, but you won't count toward quorum until you tell us you want to vote.

Why make this change?

Quorum today is measured against every member on the rolls, including members who no longer take part in elections. As membership grows, quorum becomes harder to reach and puts our elections' validity at risk.

Defining a quorum around active members is standard practice for nonprofits. Counting the entire membership roll is the outlier.

The Python Software Foundation takes a similar approach. Its voting members are asked to affirm that they intend to vote, and in June 2024 the PSF board approved waiving that affirmation for anyone who voted in the previous board election (board minutes).

No one loses their membership under this change. You remain a member and stay listed on the website. Active status only affects how we count quorum. This keeps our rolls accurate and our elections valid.

We don't want anyone excluded because they missed an email. We'll send reminders before each election and post on our blog and the forum, so everyone has plenty of notice. If you want to vote, contact us before the election opens, and we'll add you to the roll.

We've proposed the corresponding bylaw change on GitHub, discussed this proposal on the Django Forum for a while, and talked it through in person at DjangoCon US.

Next steps

This is a call for public comment. Please share your feedback by October 7, 2026, either on the pull request or, if you're a DSF member, in the members-only Forum thread.

The Board will review the comments, and if the community raises no major objections, the Board will vote on the change at our October 8th Board of Directors meeting.

18 Sep 2026 5:00pm GMT

News

Executive Director Search Extended to September 22

You don't need to be a Django or Python expert, or already part of the community, to apply for the DSF's first Executive Director role. Applications now close September 22, anywhere on Earth.

DjangoCon Europe 2027 is heading to Innsbruck, Austria! 🏔️⛷️🚠🇦🇹

Tickets are on sale and the Call for Proposals is open for five days of Django, Python, and community in Innsbruck, February 17 to 21, 2027.

---

Django Software Foundation

DSF Board monthly meeting, Sept 10, 2026

The board approved DEP 0019, discussed next steps in their Executive Director search, committed to funding Djangonaut Space for the next three years, later launched a new corporate sponsorship page, and more.

---

Python Software Foundation

Announcing the 2026 PSF Board Election Results!

Elaine Wong, Laís Carvalho, Ee Durbin, and Georgi Ker take the four open board seats out of 670 ballots cast, as Cheuk Ting Ho, Chris Neugebauer, and Denny Perez finish their terms.

Announcing the 2026 Python Packaging Council Election Results!

The first Python Packaging Council is seated: Brett Cannon and Pradyun Gedam on two-year terms, Donald Stufft, Henry Schreiner, and Ralf Gommers on one-year terms, so roughly half the council turns over each year.

Announcing the PSF Strategic Plan 2026

Feedback on the June draft reshaped the PSF's five-year plan, which now adds security baseline and vulnerability management objectives, folds translation into accessibility, and clarifies how companies can fund specific work.

---

Updates to Django

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

Last week we had 9 pull requests merged into Django by 8 different contributors - including 3 first-time contributors! Congratulations to Loïc LEFEVRE, Paul K. Gerke and Rickey Shideler for having their first commits merged into Django - welcome on board!

• Support for GEOS 3.10 is removed for Django 6.2
• Fixed a data loss issue in Django 4.0 where network rasters were deleted by GeoDjango when closed.

Thanks to the persistence of the contributors, a great deal of work has been done on the dajngo-admin yes-icons to make it rectangular, which helps people with dichromatic viewing deficiencies.

Kudos for the great work updating the tutorial and cleaning up a section to help newcomers focus on the essentials.

---

Django Fellow Reports

Django Fellow Report - Natalia

A quieter week, with a mix of security work, reviews, and follow-ups from ongoing work. I spent a good chunk of time on a security report that needed a second triage, including a detailed review of the proposed patch 🔎.

I also wrapped up more of the follow-through from DEP 20 by adapting the release checklists to the new release calendar, and resumed a PR to make EmailValidator more flexible.

And, in particularly happy news 🥳, we welcomed two new members to the Ops Team and two to the Security Team 🎉. I'm thrilled to see both teams growing!

Django Fellow Report - Sarah

This week was quite admin heavy but all positive things! The usual tickets triaged, reviewed, and authored, as well as four security issues, and lots of meetings.

Django Fellow Report - Jacob

An early report for about a day at my desk before heading out for some vacation. Multiple tickets reviewed and authored, along with security/ops/steering council/Fellows meetings.

---

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

Django: introducing django-mcpz, for making MCP servers

Because the new MCP version is stateless, a server is just a Django view: route path("mcp", server), decorate functions that take an HttpRequest, and msgspec validates arguments against schemas generated from your type annotations. No ASGI or Channels needed.

Share how you use Django with Django Probe

Tim Schilling wants decisions about what Django adds or deprecates to rest on more than gut feel, so django-probe counts which Django classes, methods, and functions your codebase actually uses and submits the tally. Sign up at djangoprobe.org, then scan and submit.

The Ultimate Question of Architecture, the Universe and Everything

Four projects, one lesson: make being wrong cheap.

Django Management Command for Bulk Import

A walkthrough of writing a custom Django management command to bulk import data.

Django: serve the change password well-known URL

One RedirectView at /.well-known/change-password lets password managers send users straight to your change password page, and Django's default 404s already pass the spec's check for servers that answer 200 to everything.

The PyLadiesCon Portal Was Spammed: 2,249 Fake Accounts. Four Months Before Anyone Noticed

A bot signed up 2,249 accounts on a Django volunteer portal to borrow its sending reputation for email bombing, and at 30 a day nobody noticed until fake accounts were 91% of the database. The fixes: django-simple-captcha, per-IP hourly rate limits, and a scheduled purge of unverified accounts.

Creating Web Widgets Using the Document Picture-in-Picture API

Picture-in-picture isn't just for video: this API floats any HTML in an always-on-top window, and the display-mode: picture-in-picture media query keeps your CSS from breaking once a component leaves the page. Desktop Chrome and Firefox only for now.

---

Django Forum

Add Plausible Tracking to DjangoProject.com?

Plausible tracking is now live on djangoproject.com and docs.djangoproject.com. This was a long-running discussion over the past 2 years. Thank you to everyone who participated.

---

Events

Django on the Med - Sept 23rd to 25th

The second Django on the Med development sprints are taking place next week in beautiful Pescara, Italy.

Django Day Copenhagen 2026 - October 2nd

Djangonauts from in and around Denmark are meeting up for the 6th edition of Django Day Copenhagen, to be held on October 2nd. It will be a full day of talks, either to be experienced online -or- at our venue.

---

Sponsored

Automatic translations on every pull request

New strings in your .po files, translated on-brand before they merge. Localhero runs as a GitHub Action, with a review page where the whole team can tweak the copy. No export, no re-import, no sync step to forget. Rails YAML and JSON too.

---

Django Job Board

The DSF's search for its first Executive Director, now open through September 22, leads this week's board, alongside a new Django role at The Developer Society, machine learning work at Provision, and a backend seat at The Cruise Brothers.

⭐ Executive Director at Django Software Foundation

🆕 Django Developer at The Developer Society

Machine Learning Engineer (Hybrid) at Provision

Django Developer at The Cruise Brothers

---

Projects

codingjoe/django-letter

Write an email once as a Django template, and django-letter sends it as HTML with inlined CSS plus a plain-text alternative derived from the same markup.

adamchainz/django-mcpz

The package behind the article above, for building MCP servers inside a regular Django project.

18 Sep 2026 3:00pm GMT

PyPy v8.0.0: release of python 2.7, 3.11, and 3.12 beta released 2026-09-19

The PyPy team is proud to release version 8.0.0 of PyPy after the previous release on May 26, 2026. This is a major new version, hence the bump to 8.0.0. It is our first release of Python 3.12, which may still have some bugs so we are calling it "beta" quality.

Why the move to 8.0.0

glibc2.28

We have updated our linux buildbots (linux64, linux32, aarch64) to use manylinux_2_28 images based on AlmaLinux 8 and glibc 2.28. These use gcc14 instead of the gcc5 previously used. So our compiled tarballs will require at least glibc2.28, which should be universally supported by now (Ubuntu 24.04 uses glibc2.39). In order to prevent confusion, we felt bumping the major version would be prudent.

cp12-abi3 support

PyPy's Python 3.12 support comes with a new model for the C layer PyObject. In order to link the C object to the internal RPython one, we have an extra field in the object ob_pypy_link, as described in-depth in rawrefcount-and-the-gc. In previous versions, this field was visible in a way that makes the PyObject struct different from the CPython one. From v8.0.0, we "hide" the PyPy-only extension in a prefix before the pointer we hand off to C-extension modules. The goal of this work is to allow PyPy to use cp312-abi3 wheels produced for CPython 3.12 and up, using the limited ABI. The required pieces have all been put in place:

• PyPy's C headers, including struct definitions like PyObject, are compatible with CPython's C headers when defining Py_LIMITED_API=0x030C0000

• PyPy no longer mangles exported function names from the limited API. In PyPy3.11 and earlier, functions like PyTuple_New were exported as PyPyTupleNew.

Still missing: the import machinery must be taught that abi3.so shared objects are valid for PyPy, and the larger ecosystem (pip, uv) must also accept that cp312-abi3 wheels are valid candidates for installation.

Yes, this is a big step. We are working with Cython and PyO3 to make sure it all will Just Work™. Hopefully this will make it easier for packages to support PyPy.

What is new in RPython code generation

PyPy is written in RPython, and has code generation to translate RPython into C as part of the VM build process. We have made some improvements to code generation in attempts to speed up the base interpreter. While the speedups have not been that impressive, we have made some steps forward:

• We now use computed gotos and more aggressively inline code. While this produces more compact sources, it does not boost performance as much as we wished.

• The source code includes comments mapping the source back to the RPython code that generated the block. This is very helpful to see exactly what is going on, and may enable further improvements.

Dropping HPy

We have dropped the internal HPy backend for PyPy. The HPy project's understanding of how to use handles instead of pointers was a good prototype, but the project did not attract enough supporters to become a new standard. The code is still in the PyPy codebase, and can be toggled on with a build option.

A revived tool comparing headers and exported functions

We revived the clang-based pyhdrdump to compare PyPy's header files to CPython's header files. See the README for more information on how it works and how to use it.

Interpreters

The release includes three different interpreters:

• PyPy2.7, supporting the syntax and the features of Python 2.7 including the stdlib for CPython 2.7.18+ (the + is for backported security updates)

• PyPy3.11, supporting the syntax and the features of Python 3.11, including the stdlib for CPython 3.11.16. Barring security issues, this will be the last release to support 3.11.

• PyPy3.12, supporting the syntax and features of Python 3.12, including the stdlib for CPython 3.12.14.

The interpreters are based on much the same codebase, thus the triple release.

We recommend updating. You can find links to download the releases here:

https://pypy.org/download.html

We would like to thank our donors for the continued support of the PyPy project. If PyPy is not quite good enough for your needs, we are available for direct consulting work. If PyPy is helping you out, we would love to hear about it and encourage submissions to our blog via a pull request to https://github.com/pypy/pypy.org

We would also like to thank our contributors and encourage new people to join the project. PyPy has many layers and we need help with all of them: bug fixes, PyPy and RPython documentation improvements, or general help with making RPython's JIT even better.

If you are a python library maintainer and use C-extensions, please consider making a CFFI version of your library that would be performant on PyPy. Failing that, PyPy will soon support the cp312-abi3 tag for limited ABI wheels. In any case, cibuildwheel supports building wheels for PyPy.

What is PyPy?

PyPy is a Python interpreter, a drop-in replacement for CPython. It's fast (PyPy and CPython performance comparison) due to its integrated tracing JIT compiler.

We also welcome developers of other dynamic languages to see what RPython can do for them.

We provide binary builds for:

• x86 machines on most common operating systems (Linux 32/64 bits, Mac OS 64 bits, Windows 64 bits)

• 64-bit ARM machines running Linux (aarch64) and macos (macos_arm64).

PyPy supports Windows 32-bit, Linux PPC64 big- and little-endian, Linux ARM 32 bit, RISC-V RV64IMAFD Linux, and s390x Linux but does not release binaries. Please reach out to us if you wish to sponsor binary releases for those platforms. Downstream packagers provide binary builds for debian, Fedora, conda, OpenBSD, FreeBSD, Gentoo, and more.

What else is new?

For more information about the 8.0.0 release, see the full changelog.

Please update, and continue to help us make pypy better.

Cheers, The PyPy Team

18 Sep 2026 11:00am GMT

17 Sep 2026 4:00am 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