fidzu : python

I started writing this blog in 2004 and, every year I published at least one post until 2022. So four years of not writing about Python ... and, actually, four years of (essentially) not writing any code. It is time for me to start writing and coding again, this time about a proposed new Python keyword: export.

Sources of frustration

There are other related sources of frustration, but this should suffice to give you the context. To address these and related issues, three related PEPs have been written:

PEP 842, since withdrawn, was written first, and suggested many changes, including creating a new list named __export__, somewhat related to __all__, and which could be used to enforce a clear separation between public and private names. With the initial version of PEP 842, attempting to import a private variable would have resulted in an ImportError. PEP 842 also included the introduction of export as a new "soft" keyword, useable in the following five cases:

• Simple declaration: export NAME
• Assignment: export NAME = VALUE
• Declaring a function or class public: export def NAME() ... or export class NAME ...
• A module re-export statement: from MODULE export NAME

PEP 843 also suggested the introduction of export as a soft keyword, but focusing on indicating that names imported into a module were meant to be public.

This means that the following three types of statements:

from module export A [, B, ...]

from module export A as B, ....

from module export *

would behave like their corresponding from ... import statements with the exception that all the names imported would be automatically added to __all__, thereby ensuring that __all__ would always be kept up to date without needing any duplicate entry from the programmer. Furthermore, a user reading the source code would immediately see which names were meant to be made public.

PEP 844: instead of introducing an new keyword, PEP 844 suggests the addition of two functions from the publicly available atpublic to Python's builtins. This library includes two decorators, @public and @private, that can be used to indicate how these names are intended to be used; in addition, @public automatically adds the name of the function or class to __all__. Simple assignments can be also declared to be "public" using a cleverly built function.

The introductions of these PEPs has lead to many long discussion threads on Python-discuss (PEP 842 - discuss, PEP 842 - revision, PEP 842 - postmortem, PEP 843 - discuss, PEP 844 - discuss, General discussion about what public means in Python, and perhaps other).

For now the discussion seems to have died down.

Source of inspiration

As I mentioned previously, I have done almost no programming in the past four years. I still read about Python, but didn't have the motivation to actually write code. That is, until I read these discussions and pondered if it would not be possible to simply "try out this new syntax". This lead me to go back to working on a fun project , and write two new import hooks, documented here and here.

With these, you can try out right now what it would be like to use the proposed export keyword cases suggested in PEP 842 as well as in a subset of those suggested in PEP 843.

Go try it out, and let me know what you think!

In the meantime, I plan to continue working on ideas, and resume working on friendly/friendly-traceback as well as on Reeborg's World, and implementing many of the suggestions made by users over the past four years.

21 Sep 2026 5:24pm GMT

Should you put a tourniquet in your first aid kit? Maybe, but you should know some things before you do:

• Training is more important than any piece of gear. Most bleeds can be stopped with direct pressure and/or proper wound packing - and both can be done with your hands and any old piece of fabric you have lying around. If you don't know what "direct pressure" or "wound packing" means, or if you want to practice, take a course! A Stop The Bleed course is an excellent investment, and will go into all forms of bleeding control (including how to properly apply a tourniquet.) Most basic first aid courses will also cover bleeding control to some extent, though wilderness-oriented courses (for example, Wilderness First Aid) will typically go into more depth.

  (These are US-oriented suggestions; readers from other areas, I'd love for you to get in touch and let me know the equivalents in your country.)

• Once you do take that training, you'll learn that the most important supplies for bleeding control are gloves, a stretchy bandage and plenty of gauze. Get those first, then think about other supplies.

• You probably don't need a tourniquet in your first aid kit. Major bleeds that require tourniquets and aren't immediately fatal - are rare outside of some specific circumstances (see below). Most people will never encounter one of these circumstances. While there's nothing wrong with having one (if you're trained to use it), they're expensive and don't last forever. If you've got disposable income, and the training, sure, go ahead; but for most people, your money is better spent on something else. (Narcan, for example: you've got a much higher chance of saving a life with Narcan than with a tourniquet.)

• You probably do need a tourniquet if you:

  • work with highly dangerous power tools (e.g. table saws, chainsaws),
  • use firearms (e.g. target shooting, hunting) or are likely to be shot (e.g. military), or
  • ride a motorcycle.

  This isn't an exhaustive list; you may be able to think of other situations. The common factor is exposing yourself to a risk of sudden massive hemorrhage. If you're in one of those situations, you should have a tourniquet and know how to use it.

• If you do decide to have a tourniquet, you need to know how to use it. They're not intuitive to use, especially if you're stressed, and putting one on yourself can be tricky. Most people, without training, don't make the tourniquet nearly tight enough - they need to be shockingly tight.

  Take a course, and buy a trainer tourniquet to practice. You don't want to practice with your real tourniquet, because they're single use. Tightening them correctly can weaken the strap to the point that they may not work a second time; hence the need for the trainer. (This is another reason why I say that tourniquets are expensive.) Practice applying a tourniquet to yourself and to someone else, and crank it down correctly. It should cut off circulation (that's the point), and will hurt. Practicing like this is safe as long as you don't leave the tourniquet tightened for longer than a few minutes.

• Buy a windlass-style tourniquet- that's the kind with a velcro band and tightening stick. Other styles (like the stretchy strap you might see when you get blood drawn for lab work) don't work as well, and improvised tourniquets (e.g. a belt or climbing rope or whatever) don't work at all. Get it from a reputable source: places like Amazon often sell fakes that'll break under proper tension. They should be expensive (around $40 each).

  The gold standard are C-A-T tourniquets; I get mine from North American Rescue.

• An alternative to a tourniquet that's nearly as effective and easier to use is an Israeli Bandage. They're much cheaper (typically less than $10 each), and are easy to apply (but still practice). They're great, you should have one in your FAK even if you also have a tourniquet.

• Some people put clotting agents or bandages (e.g. QuikClot) in their bleeding control kits. Opinion on these is split: they do work, but they leave gunk in the wound that your ER doc is going to need to cut out. This'll prolong recovery and cause worse cosmetic outcomes. They also can't stop the big bleeds that you'd need wound packing or a tourniquet to stop. Many ER doctors and nurses I've talked to don't like clotting agents, and recommend against them; but on the other hand, several remote/austere medicine practitioners I've spoken to make compelling cases for them. So: think about the tradeoffs.

• Tourniquets expire - the nylon weakens over time, to the point that tightening an old tourniquet might break it. So that tourniquet your friend kept when he left the army should go in the trash, and you need to check your kit yearly-ish and replace any past their expiration date.

So what do I do?

I have tourniquets in two places:

1. In my shop. I have a table saw in there, and several other things that spin sharp metal at high speed.
2. In a small first aid pouch that I wear on my belt when I'm using my chainsaw.

Both of those bleeding control kits also have an Israeli bandage, vetwrap, and gauze. I probably ought to have gloves but I don't; the person doing the bleeding is going to be me or a loved one, and I can't be bothered to keep replacing them as they get all gross and sticky from the heat.

None of my other first aid kits have tourniquets. My backcountry kits don't need them; I'm not going to encounter a situation in the wilderness that requires a tourniquet. (I would add one if I went on a hunting trip.)

There's an argument to be made that I should carry one in the kit in my car - because I have emergency medical training, I'd want to stop and help if I witnessed a traffic accident, and those are situations where perhaps a tourniquet could make a difference. However, I'm concerned that the heat of the car will degrade the tourniquet faster than I'd expect, and so if I did apply it, it could fail. And I'm confident enough in my ability to control bleeding with pressure until EMS arrives.

Was this helpful? I've been thinking about writing a longer series about first aid kits (how I think about building them, and what goes in mine), of which this could become a part. If that's something you'd like to read, get in touch.

21 Sep 2026 5:00am GMT

Some of the most satisfying work I do happens one on one. You arrive with a real problem from your real job - code that will not behave, an architecture you are unsure about, a Git situation that has you stuck - and an hour later it is smaller, or gone.

I have offered these private coaching sessions for years, mostly to people who thought to ask. What I never did was describe them properly anywhere, which is a strange way to run something I enjoy this much.

So: I've now set up a page all about my coaching, at lernerpython.com/personal-coaching. Take a look - and if you need this kind of help, let's talk!

What happens in an hour

Whatever you need. The session is yours, and people use it in very different ways:

• You show me code you have written, and I tell you what I would change and why.
• We plan a project before you write any of it, which is usually cheaper than planning it afterward.
• We pair-program through a problem that has had you stuck for days.
• You ask me the Git questions you have been quietly avoiding since 2019.
• We work out where Claude Code actually fits into the way you already work.
• You talk through a career decision, an interview, or what to learn next.

You do not need an agenda, or a tidy repository, or a well-formed question. "Here is my code, and here is what confuses me" has started plenty of excellent sessions.

Two things that make it work

It is private. Your code, your employer's code, the architecture you are unsure about, the concept you feel you should have learned years ago: none of it goes anywhere. Ask me the question you would never ask in a public forum. That is rather the point of meeting one on one.

You get a recording. Nobody thinks clearly while taking notes. When we finish, I send you the video of the session, along with anything we built together - code, notes, a diagram, a Jupyter/Marimo notebook, a CLAUDE.md, or just a plan. It's all yours to keep, and to use as you see fit.

What it costs, and what it does not require

A session is one hour on Zoom, for $300.

It has nothing to do with a LernerPython membership. You do not need to be a member, and booking a session does not sign you up for anything else. One hour, one payment, no obligation. If it helps and you want another in a month, book another; most people book once, get unstuck, and carry on.

Let's talk!

Pick a time on my calendar, or read the details first on the coaching page.

If nothing on the calendar suits you, e-mail me at reuven@LernerPython.com and we will find a time that does. I am happy to get up early or stay up late for a session like this, wherever in the world you are. Ask, and we will work it out.

And if you are not sure whether your problem is a good fit for an hour, e-mail me and ask. I will tell you honestly, even when the answer is that you don't need me.

The post Get Python help, one on one: my coaching sessions appeared first on LernerPython.

20 Sep 2026 10:37am GMT

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

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

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