fidzu : python

News

See You in Chicago in One Month!

In just one month, developers, maintainers, educators, and Django enthusiasts from around the world will gather in Chicago for DjangoCon US 2026.

DSF member of the month - Katherine "Kati" Michel

Kati is a longtime member of the Django community who has been a speaker, organizer of DjangoCon US, and member of DEFNA's board of directors. She shares some insightful thoughts on the current state of Django and where it can go from here, especially around AI.

Next Stop Pescara!

Looking forward to this year's Django on the Med 🏖️? Perhaps you should come? And what to do if you can't!

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 10 different contributors - including 2 first-time contributors! Congratulations to Mundur and Philip Narteh for having their first commits merged into Django - welcome on board!

News in Django 6.2:

• In the asynchronous request path, error responses (such as those rendered by handler404 and handler500) are now rendered on the request's thread-sensitive thread, rather than on a shared thread pool, so that database connections used during error handling are managed by close_old_connections().
• The admin view_on_site URL now consistently returns an HTTP 403 response when a staff user lacks view or change permission for the target model.
• The admin history view now checks permissions before object existence, consistently returning an HTTP 403 response for staff users without the view or change permission regardless of whether the object exists.

Django Fellow Reports

Django Fellow Report - Natalia

Focus this week was on the djangoproject.com email incident 📧🧱 and security work 🔐. I worked with Ops to diagnose and resolve the outage, addressing the source of abuse in the account registration flow. In parallel, I continued security reviews (including GeoDjango) and handled incoming reports 👁️. Overall brain ended up quite fried 🧠🍳😩.

Django Fellow Report - Sarah

Triaged a couple of interesting tickets, including one around paginator solutions. Reviewed four more and authored three. Also weighed in on the move to Playwright for integration testing and worked on six security reports.

And her baby boy now has his first two teeth.

Django Fellow Report - Jacob

Like last week, I focused almost all of my attention on improving our patches for the same two pending security reports. One reporter thanked us for our professional handling and brought a smile to my face when adding, "as I am sure you are getting completely slop cannoned all the way down." 🫟

More steady progress reviewing the GSoC work on expressions in SQL FROM clauses, too.

DjangoCon US

LAST DAY! 10% off + guaranteed t-shirt +swag ends July 31st)

Quick heads-up: today is the last day to save on DjangoCon US 2026 and the last day we can guarantee your t-shirt and tote bag for in-person registrations.

Articles

Setting Django's DEBUG safely

DEBUG=True does far more than turn on pretty error pages: it exposes stack traces and configuration to attackers, disables error reporting, degrades query performance, and serves unminified static files. A grep of Django's own source shows the setting changing behavior across more than two dozen files, which is the real argument for never letting production depend on it.

Nifty Django Feature: setUpTestData

setUpTestData() runs once per test class where setUp() runs again for every test method, so moving shared fixtures into it cuts repeated create and destroy work off your suite. A short Pet and Species example makes the difference concrete: the species row is built once for the whole class, while anything created in setUp is rebuilt for each test.

Django: release code words up to 6.1

Every Django release announcement hides a "code word" introducing the new features, and this post tables them all from 1.7 through 6.1, each linked to its Wiktionary definition and scored for rarity using the wordfreq package. Carlton's mezcla (3.2) wins on obscurity by not appearing in the English frequency data at all, while Sarah's composite (5.2) was a wink at that release's composite primary keys.

Python: spy on function calls with unittest.mock's wraps

Despite the name, unittest.mock builds spies as well as mocks: pass wraps and calls fall through to the real function and return real results, while the mock still records them for assertions. A caching example checks that compute_owl_sound() runs only once across two owl_sound() calls, and pairs it with autospec=True, which is optional when spying on functions but required for methods.

Python: inspect interleaved unittest.mock calls with attached mocks

To assert the order of calls across several mocks, attach them to a parent so its mock_calls records everything on one interleaved timeline. Methods attach themselves when you build the parent with create_autospec(Kettle, instance=True), while separate module-level functions need an explicit attach_mock() before you can check the whole sequence in a single assertion.

Podcasts

Talk Python #556: Updates on Django's Async Story - Carlton Gibson

Carlton answers all your questions on Django, async, what to be excited about in Django 6.1, and more. Well worth the full listen.

Sponsored

It's hard to ask to meet a stranger

So I'll go first. I'm Tim Schilling. I enjoy talking to people about software, Django and career development. I recently pivoted to specifically focus on helping others in their careers. If you could use some support, or just want to talk with me, set up a call with me!

Videos

No More Spreadsheets! Building PyLadiesCon Infrastructure with Python and Django - Mariatta

From PyCon US, Mariatta outlines how PyLadies said no to spreadsheets and instead started building out its own conference infrastructure using Python and Django.

Django Job Board

Two new listings lead the board this week: a one-year Security Developer role at the Python Software Foundation covering CPython vulnerabilities and PyPI malware, plus senior full-stack work at Hive Collective, with Django roles at MyOme and Fusionbox still open.

Security Developer at Python Software Foundation 🆕

Senior Full Stack Engineer at Hive Collective 🆕

Senior Backend Engineer at MyOme

Python + TypeScript Engineers at Fusionbox

Projects

Spwig/commerce

Spwig is a full-stack, self-hosted e-commerce platform on Django 5, now open source under AGPL-3.0. Server-rendered storefront, admin, REST API, POS, and page builder in a single modular monolith.

31 Jul 2026 3:00pm GMT

Exciting news! The third edition of the Python Automation Cookbook is out, featuring a vibrant new cover and over 100 pages of fresh AI content. Aimed at Python enthusiasts of all levels, it retains classic recipes while introducing innovative ways to incorporate AI in code. A fantastic addition to any developer's library!

31 Jul 2026 10:38am GMT

The inaugural Python Packaging Council Election nomination period opens next week on Tuesday, July 28th, 2:00 pm UTC and closes on Tuesday, August 11th, 2:00 pm UTC.

The Python Packaging Council (PPC) will be the technical decision-making body for the interoperability specifications that govern how Python packages are built, distributed, and installed. It will also coordinate efforts among packaging tool maintainers, the Python core team, and the broader community.

Do you have a vision for improving the Python packaging experience? Do you make the tools used to build and consume Python packages? Are you passionate about building communities, consensus, and standards focused on the user experience? If these resonate with you, and you have the time to attend regular meetings and participate in the standardization process, you should consider running for the inaugural PPC!

We're looking for candidates who can build bridges between projects and communities, who enjoy working with a very large community of passionate volunteers, and have a willingness to represent the wider community ahead of any single tool, project, or employer. We also welcome candidates who have a diverse set of skills and experiences, including open-governance experience, community stewardship, fundraising knowledge, and (of course!) technical expertise in Python packaging and distribution.

PEP 772 does provide non-binding operational suggestions, which hint at how the council could function. As this is the inaugural PPC, the individuals serving on it will be establishing the initial operating procedures, scope, interests, and agenda that future councils will build upon. Notably, "establishing specific processes for [the] Packaging Council and PyPA relationship" is something that the inaugural Packaging Council is expected to do.

The 2026 inaugural election fills all five seats on the PPC. The two candidates receiving the highest number of votes shall be designated Cohort A with a two year term, and the three candidates receiving the next highest number of votes shall be designated Cohort B with a one year term.

In future elections, each cohort will be elected for a full two-year term in alternating years, so that roughly half of the PPC turns over each cycle.

• Nominations open: Tuesday, July 28th, 2:00 pm UTC
• Nomination cut-off: Tuesday, August 11th, 2:00 pm UTC
• Announce candidates: Thursday, August 13th
• Voter affirmation cut-off: Tuesday, August 25th, 2:00 pm UTC
• Voting start date: Tuesday, September 1st, 2:00 pm UTC
• Voting end date: Tuesday, September 15th, 2:00 pm UTC

Not sure what UTC is for you locally? Check this UTC time converter!

You can nominate yourself or someone else. If you're nominating someone else, we'd encourage you to reach out to them first to make sure they're excited about the opportunity and give them a heads up that they'll need to submit their own nomination statement too. Remember, nominees must themselves be PSF voting members, and nomination statements must include information about the nominee's relevant affiliations.

To submit a nomination for yourself or someone else, use the 2026 PPC Election Nomination Form on our website. The form will open on Tuesday, July 28th, 2:00 pm UTC and close on Tuesday, August 11th, 2:00 pm UTC.

Every PSF Voting Member (Supporting, Contributing, and Fellow) needs to be a member in good standing by August 25th and affirm their membership to vote in this election. You should have received an email with information on how to affirm your voting status.

You can see your membership record and status on your PSF Member User Information page. If you are a voting-eligible member and do not already have a login, please create an account on psfmember.org first and then email pc-elections@python.org so we can link your membership to your account.

31 Jul 2026 8:58am GMT

For July 2026, we welcome Katherine "Kati" Michel as our DSF member of the month! ⭐

Kati is involved in the Django community for many years. She was a DEFNA Director for 8 years and DjangoCon US Website Chair and Co-Chair. She is a DSF member since December 2017!

You can learn more about Kati by visiting Kati's website and her GitHub Profile.

Let's spend some time getting to know Kati better!

Can you tell us a little about yourself? (hobbies, education, etc)

In 2002, I was living in Lawrence, Kansas and working for government contracts supporting US Citizenship and Immigration Services and the US Department of Education. While working for USCIS, I spoke to tens of thousands of people from around the world, but hadn't seen much of the world myself. In 2009, I decided to move to England and earn a master's degree from Lancaster University Management School. During the program, I was fortunate to have an internship in the IT Change Management Department of Co-operative Financial Services/Britannia Building Society.

It feels full circle that I am now a software engineer at JPMorganChase, working in Infrastructure Platforms, Databases Department.

How did you start using Django?

While living in Lawrence, I visited the Lawrence Public Library often. I would sometimes drive past the nearby Lawrence Journal World and had no idea that Django was being invented there.

During my internship at CFS/Britannia Building Society in England, I was immersed in technology and loved it. Although it was a tumultuous time due to the subprime mortgage crisis, I was left with an insatiable curiosity about programming. That is how I learned about Django, and I have been using Django ever since.

What other framework do you know and if there is anything you would like to have in Django if you had magical powers?

In addition to Python/Django, I work with React.

At DjangoCon US 2025, Will Vincent commented during his talk "Django for AI" that Django "never really 'owned'" the niche of classic Machine Learning models, but should have, because it's great for small and medium ML models. He recently asked Django Project Forum if Django should have an official skills.md like FastAPI now has. These are important conversations to have.

If I had magical powers, I would maintain the stability and maturity many Django users celebrate while making targeted enhancements to help it better serve developers who are reaching for FastAPI or JavaScript frameworks first. Providing Django's benefits while meeting the use case is win-win.

Django already supports many modern patterns. Clear starter guides and code examples showing how to build a classic ML application, LLM chat bot, async workflows, React/Angular/Vue integration, and APIs, while taking advantage of the benefits Django offers, could help developers discover it better.

Marlene Mhangami and Benjamin "Zags" Zagorsky also gave some ideas for how to approach this in their respective DjangoCon US 2025 keynotes.

Author's note: You can watch Marlene Mhangami's keynote and Benjamin "Zags" Zagorsky's keynote here.

What projects are you working on now?

In my work, I am part of a team building a new on-premises caching service from the ground up. I design distributed system topology, write code for a React UI and Django control plane that orchestrate tasks to provision these distributed systems based on internal customer requirements, create Ansible playbooks to manage the servers, and do Red Hat Enterprise Linux admin. It's not a typical Django use case, but fun and fascinating in its own right.

Which Django libraries are your favorite (core or 3rd party)?

I had a website query that was becoming progressively slower as the data in the database grew. I installed django-silk, a live profiling and inspection library, diagnosed an N+1 problem, and had an aha moment as I watched the number of SQL queries in the django-silk dashboard greatly reduce with each new addition of a prefetch_related or select_related. It felt like magic. django-silk has been one of my favorite libraries ever since.

htmx and django-template-partials have been a joy to use together to create AJAX-like web UI functionality directly in HTML, without the need for JavaScript. As of Django 6.0, the Django Template Language now supports template partials. The htmx website has a fun UI Examples page to demo what it can do.

I am a fan of django-ninja. I like its use of Pydantic schemas, type hinting, and OpenAPI integration.

What are the top three things in Django that you like?

1. Django was invented at a newspaper. The Django ORM and admin are arguably its killer feature. Not every popular framework has a built-in ORM and admin that enable users to quickly structure and manage data.

2. Django's "batteries included" philosophy and rich library ecosystem enable developers to focus on building applications without re-inventing the wheel.

3. Django has strong security protections out of the box and a mature security policy.

I'm curious, how did you started to contribute to DjangoCon US? Do you have any advice for someone who might be considering joining the board of directors if the opportunity arose?

While looking through GitHub projects, I stumbled upon the DjangoCon US website code. I had a feeling that becoming part of a community like this would be life-changing, and it was. In March of 2016, I began helping with the DjangoCon US 2016 website. It was an invaluable opportunity to learn my way around Git, GitHub, and the website code. 2017 was a very eventful year. I became the DjangoCon US 2017 Website Chair, joined the DEFNA Board, and was hired by the web development agency contracted to create the DjangoCon US website.

I served as DjangoCon US Website Chair or Co-chair from 2017 to 2021 and DEFNA Board Member from 2017 to 2025, including several years as corporate secretary. Serving on the board gives you the opportunity to manage the higher level details of DjangoCon US, such as budgeting, location selection, contractor procurement, and volunteer oversight. You will also have the opportunity to grow Django outreach across North America, for instance, by awarding event grants. Being on the board was an honor and one of the most rewarding experiences of my life.

I've never seen a more practical write-up of how to excel in a board position than former DEFNA President Jeff Triplett's post "PSF Elections how I am voting.".

You have been a speaker, an organizer of DjangoCon US, and a member of DEFNA's board of directors. Having observed the conference from many different perspectives over a period of time, how do you think DjangoCon US has evolved?

The conference structure has evolved to fit the times and talk subject trends have evolved (async, locality of behavior ecosystem, and AI come to mind), but my favorite evolution of all has been the major improvement in diversity and inclusion over time.

DjangoCon US increased the number of talks by women from around 6% in 2010 to nearly 50% in 2016. This was accomplished through intentional outreach. PyLadies and Django Girls have both played a major role.

In 2023, the conference was an important platform for the newly formed, self-organized Black Python Devs organization. By one organizer's count, we had around 10 Black speakers, and a Django Girls workshop had a majority of Black participants. In 2024, the conference hosted the Black Python Devs Leadership Summit.

From a Django Core perspective, at DjangoCon US 2018, former Django Fellow Carlton Gibson acknowledged that the community had become more diverse than ever, but the core contributors had continued to be white guys. The launch of Djangonaut Space in 2024 by a small group of community members has been a game changer. Djangonaut Space is a highly effective mentorship program that equips its cohort members to contribute to Django and its ecosystem, with a focus on inclusion.

You have been a speaker multiple times, do you have any advice for someone considering starting speaking one day?

My advice to aspiring public speakers is to start with the opportunities you can get and work your way up: give a presentation to your department (do a practice run to colleagues for feedback), give a talk to a local meetup, give a lightning talk at a conference, enlist the help of a talk mentor and submit to a conference CfP (especially those that welcome newcomers - DjangoCon US is one of them), and don't be discouraged by rejections.

As a conference attendee, I've seen some incredible speakers. Russell Keith-Magee immediately comes to mind. I appreciate the candor of highly effective public speakers who acknowledge that it is a skill that can be developed. I often remember an anecdote Nina Zakharenko once told. She got her start in public speaking when someone challenged her to do a lightning talk at a conference. She got the microphone caught in her hair during the talk. Years later, she expertly keynoted PyCon US. Don't wait for, or expect perfection.

After so many times in the Django community, what makes you stay?

I enjoy the Django tool ecosystem, and the people are wonderful. I have a lot of friends in this community who inspire me and are there for me.

How do you envision the future of Django from your perspective?

Last year was Django's 20th birthday. I'm optimistic that Django and its community will be thriving 20 years from now.

Do you remember your first contribution to Django and in open source? (Can be Django ecosystem, code contribution or not)

At DjangoCon US 2019 sprints, I made my first contribution to Django Core with the help of Carlton Gibson. I added instructions for running tests using django-docker-box. I would love to contribute to Django again.

What are your hobbies or what do you do when you're not working?

In my personal time, I love exploring new and interesting places, discovering great food, watching documentaries, and taking photographs.

Is there anything else you'd like to say?

Thank you for having me! I really enjoyed this interview.

Thank you for doing the interview, Kati !

29 Jul 2026 9:48pm GMT

News

Django 6.1 release candidate 1 released

This is the final opportunity to try out the new version before Django 6.1 is released. Try it, run your test suite, and report anything that breaks!

The DjangoCon US 2026 schedule has been released!

The talk lineup is out, covering Django 6.0 and 6.1 features, modern deployment patterns, GeoDjango at scale, and lightning talks across all three days.

PyPI Releases now reject new files after 14 days

PyPI will reject new files uploaded to releases older than 14 days to limit the impact of compromised publishing tokens or workflows.

Planned Updates to the PyPI User Interface

PyPI's first UI refresh since 2018 will roll out in phases over the coming months, surfacing more security signals on package pages. The first phase is staged on TestPyPI now and ready for your feedback.

Wagtail CMS News

What our AI guiding principles actually mean

Wagtail unpacks its refreshed AI guiding principles and how they steer adoption in practice, starting with a firm commitment: no AI dependency in Wagtail core, with AI features staying opt-in through packages like Wagtail AI.

Django Software Foundation

DSF Board monthly meeting, July 09, 2026

Minutes from this month's DSF Board meeting: a host for DjangoCon Europe 2027 was approved, a new Google Summer of Code Working Group was chartered, Executive Director hiring continues with guidance from the PSF, and grants went to PyCon Cameroon and PyCon Africa.

Updates to Django

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

Last week we had 17 pull requests merged into Django by 11 different contributors - including 6 first-time contributors! Congratulations to Tom Most, CharulL00, Sina Chaichi Maleki, Harvey Bellini, Stephanie and Vismay for having their first commits merged into Django - welcome on board!

News in Django 6.2:

• The MiddlewareMixin class moved from django.utils.deprecation to django.middleware. The old import path is deprecated in Django 6.2.
• Whether to suppress an ImportError escaping from a settings module is configurable by the new BaseCommand.requires_settings attribute (default True). In previous versions, such errors were always suppressed.
• The minimum supported version of asgiref is increased from 3.9.1 to 3.12.1.

Thanks to the continuous efforts of the contributors, a SQLite regression test has also been added to inspectdb when a table has a foreign key that references sqlite_master. (#25243)

Support for prefers-color-scheme was also implemented, adding dark mode CSS overrides for the technical 500 (traceback) and 404 debug views. (#35875)

Django Fellow Reports

Django Fellow Report - Natalia

A security-heavy week: two patches for confirmed vulnerabilities, deep-dive reviews of two more, and prep for the August release with CVE metadata and prenotifications, plus continued iteration on EmailValidator improvements.

Django Fellow Report - Sarah

Reviews across Django and djangoproject.com, including the Selenium to Playwright migration and admin widget fixes, plus a new GitHub Action to test djangoproject.com against Django main and engagement on six security issues across Django and djangoproject.com.

Django Fellow Report - Jacob

Sustained attention on a couple of security reports, alongside triage and a long review list covering dark mode error pages, Oracle Test Pilot in CI, and the asgiref 3.12 update that enables free-threading tests.

Python Software Foundation

Get Ready: PSF Board Nominations Opening Soon!

PSF Board nominations open July 28, with voting September 1-15. If you're a voting member, affirm your intent to vote by August 25.

Get Ready: 2026 Python Packaging Council Nominations Opening Soon!

Nominations for the first-ever Python Packaging Council open July 28 and close August 11.

Events

Django Girls Chicago - August 22, 2026

Django Girls returns the Saturday before DjangoCon US in Chicago: build your first website, eat free food, and meet fellow aspiring Django developers. The free workshop is limited to 45 people and applications close August 12, so apply early.

Preparing for sprints as a project leader (at DjangoCon US)

As DjangoCon US approaches in just a few weeks time, here are some good tips on how to make the most out of the sprints following the tutorial talks.

A First-Timer's Guide to Navigating America

If you are attending DjangoCon US, please do follow the news section of the website, as it has helpful articles like this one, as well as info on childcare at the conference, and more.

Sponsored Link

When is it worth paying for a mentor?

Thinking about hiring a mentor to grow as a Django developer? Here are a few honest questions to help you get clarity on whether now's the right time.

Articles

Django: introducing django-crawl

Adam Johnson introduces django-crawl, a new package that crawls your whole site with Django's test client (via links, sitemaps, or a Python API) to surface broken pages before your users do.

Nifty Django Feature: Form Templates

Django's form templates separate a form's HTML from the view that processes it: set template_name on the form for one reusable layout, or on an individual field when a single input needs custom markup.

Some more things about Django I've been enjoying

Building a "2010 style" backend-heavy web app, this writeup highlights Django's readable query builders, handy template filters like querystring and json_script, and the comfort of automatic migrations. It also covers the author's practical performance questions, including a misconfigured cached template loader and why it mattered.

Browser Push Notifications for a Django Website

A step-by-step tutorial on adding browser Web Push notifications to a Django site using VAPID keys, a service worker, and a Huey background task, so you get OS-level notifications even when the admin tab is closed.

Is it time to go back to Django?

Some arguments for Django's opinionated, batteries-included approach in the AI-coding era, since it limits the decisions an AI agent has to make and reduces the chance of it going astray.

Deploying Web Apps in 2026: My EuroPython Conference Talk

The written version of Will Vincent's EuroPython talk, which maps today's hosting landscape and builds a ten-step mental model of everything your dev server quietly handles for you, from WSGI servers and static files to running migrations at release time.

My EuroPython 2026 - Paolo Melchiorre

A day-by-day recap of Paolo Melchiorre's EuroPython 2026 in Kraków, compiled from Mastodon posts and photos, from the Python Steering Council update to rethinking asyncio for free-threaded Python and time with the Django community at the booth.

EuroPython 2026 Recap - Will Vincent

Highlights from a packed week in Kraków, where the standout theme was agentic AI workflows, with teams split between off-the-shelf tools and heavy internal tooling.

PyCon US 2026 Recap - Katherine Michel

Katherine's famous PyCon recap is here! Security and AI front and center, PSF and PyPI updates, steering council priorities for free-threading, and lots of great pictures.

Events

Django on the Med

Three days of Django development sprints, September 23-25 in Pescara, Italy. The second edition is free to attend and gathers Fellows, board and Steering Council members, and contributors new and experienced to push Django forward.

Django Day Copenhagen 2026

October 2 in Copenhagen. The first three talks are by Marijke Luttekes, Efe Öge, and Denny Biasiolli.

Django Job Board

Three new remote openings join the board this week, from AI-native full-stack work at Hive Collective to Django backend engineering for genetic testing at MyOme and Python + TypeScript roles at Fusionbox.

Senior Full Stack Engineer at Hive Collective 🆕

Senior Backend Engineer at MyOme 🆕

Python + TypeScript Engineers at Fusionbox 🆕

Freelance Full-Stack Web App Developer at Mindrift

Projects

adamchainz/django-crawl

An in-process site crawler using Django's test client.

FROWNINGdev/django-orm-lens

See your entire Django schema (every model, field, and relationship) in your editor, terminal, or AI agent, one keystroke away from a live ER diagram.

24 Jul 2026 3:00pm GMT

Did you know that each Django release has a "code word" associated with it? It's hidden in plain sight, in the announcement blog post describing the list of features coming in the next version. I think this is a lovely little tradition.

I last covered the list back in 2021, for Django 3.2 (post). This post expands the table up until Django 6.1, which is expected next month (the first release candidate came out earlier this week).

Each code word links to its Wiktionary entry so you can see the definition. The word frequency column is based on the English data in the wordfreq Python package, as occurrences per billion words, so higher numbers mean the word is more common.

Some observations on the newer entries:

• Carlton's mezcla (Django 3.2) wins on rarity, as it doesn't even appear in the English word frequency data.
• Sarah's composite (Django 5.2) was a wink at the composite primary key support added in that release.
• I ended my previous post of code words with the signoff "May your projects have their own mélange of new features". Perhaps this inspired Jacob to make the upcoming Django 6.1's code word mélange? I had better nail the signoff on this one then!

24 Jul 2026 4: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

Let's say you're writing a Python library.

In this library, you have some collection of state that represents "options" or "configuration" for a bunch of operations. Such a set of options is a bundle of potentially ever-increasing complexity. Thus, you will want it to have an extremely minimal compatibility surface, with a very carefully chosen public interface, that is either small, or perhaps nothing at all. Such an object conveys state and might have some private behavior, but all you want consumers to be able to do is build it in very constrained, specific ways, and then pass it along as a parameter to your own APIs.

By way of example, imagine that you're wrapping a library that handles shipping physical packages.

There are a zillion ways to do it ship a package. There are different carriers who can ship it for you. There's air freight, and ground freight, and sea freight. There's overnight shipping. There's the option to require a signature. There's package tracking and certified mail. Suffice it to say, lots of stuff.

If you are starting out to implement such a library, you might need an object called something like ShippingOptions that encapsulates some of this. At the core of your library you might have a function like this:

1
2
3
4
5

async def shipPackage(
        how: ShippingOptions,
        where: Address,
    ) -> ShippingStatus:
    ...

If you are starting out implementing such a library, you know that you're going to get the initial implementation of ShippingOptions wrong; or, at the very least, if not "wrong", then "incomplete". You should not want to commit to an expansive public API with a ton of different attributes until you really understand the problem domain pretty well.

Yet, ShippingOptions is absolutely vital to the rest of your library. You'll need to construct it and pass it to various methods like estimateShippingCost and shipPackage. So you're not going to want a ton of complexity and churn as you evolve it to be more complex.

Worse yet, this object has to hold a ton of state. It's got attributes, maybe even quite complex internal attributes that relate to different shipping services.

Right now, today, you need to add something so you can have "no rush", "standard" and "expedited" options. You can't just put off implementing that indefinitely until you can come up with the perfect shape. What to do?

The tool you want here is the opaque data type design pattern. C is lousy with such things (FILE, pthread_*_t, fd_set, etc). A typedef in a header file can easily achieve this.

But in Python, if you expose a dataclass - or any class, really - even if you keep all your fields private, the constructor is still, inherently, public. You can make it raise an exception or something, but your type checker still won't help your users; it'll still look like it's a normal class.

Luckily, Python typing provides a tool for this: typing.NewType.

Let's review our requirements:

1. We need a type that our client code can use in its type annotations; it needs to be public.
2. They need to be able to consruct it somehow, even if they shouldn't be able to see its attributes or its internal constructor arguments.
3. To express high-level things (like "ship fast") that should stay supported as we add more nuanced and complex configurations in the future (like "ship with the fastest possible option provided by the lowest-cost carrier that supports signature verification").

In order to solve these problems respectively, we will use:

1. a public NewType, which gives us our public name...
2. which wraps a private class with entirely private attributes, to give us an actual data structure, while not exposing the constructor,
3. a set of public constructor functions, which returns our NewType.

When we put that all together, it looks like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

from dataclasses import dataclass
from typing import Literal, NewType

@dataclass
class _RealShipOpts:
    _speed: Literal["fast", "normal", "slow"]

ShippingOptions = NewType("ShippingOptions", _RealShipOpts)

def shipFast() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts("fast"))

def shipNormal() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts("normal"))

def shipSlow() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts("slow"))

As a snapshot in time, this is not all that interesting; we could have just exposed _RealShipOpts as a public class and saved ourselves some time. The fact that this exposes a constructor that takes a string is not a big deal for the present moment. For an initial quick and dirty implementation, we can just do checks like if options._speed == "fast" in our shipping and estimation code.

However, the main thing we are doing here is preserving our flexibility to evolve the related APIs into the future, so let's see how we might do that. For example, let's allow the shipping options to contain a concrete and specific carrier and freight method:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

from dataclasses import dataclass
from enum import Enum, auto
from typing import NewType

class Carrier(Enum):
    FedEx = auto()
    USPS = auto()
    DHL = auto()
    UPS = auto()

class Conveyance(Enum):
    air = auto()
    truck = auto()
    train = auto()

@dataclass
class _RealShipOpts:
    _carrier: Carrier
    _freight: Conveyance

ShippingOptions = NewType("ShippingOptions", _RealShipOpts)

def shipFast() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts(Carrier.FedEx, Conveyance.air))

def shipNormal() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts(Carrier.UPS, Conveyance.truck))

def shipSlow() -> ShippingOptions:
    return ShippingOptions(_RealShipOpts(Carrier.USPS, Conveyance.train))

def shippingDetailed(
    carrier: Carrier, conveyance: Conveyance
) -> ShippingOptions:
    return ShippingOptions(_RealShipOpts(carrier, conveyance))

As a NewType, our public ShippingOptions type doesn't have a constructor. Since _RealShipOpts is private, and all its attributes are private, we can completely remove the old versions.

Anything within our shipping library can still access the private variables on ShippingOptions; as a NewType, it's the same type as its base at runtime, so it presents minimal¹ overhead.

Clients outside our shipping library can still call all of our public constructors: shipFast, shipNormal, and shipSlow all still work with the same (as far as calling code knows) signature and behavior.

If you need to build and convey some state within your public API, while avoiding breakages associated with compatibility churn, hopefully this technique can help you do that!

Acknowledgments

Thanks for reading, and 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.

22 May 2026 12:33am GMT