#752 - SEPTEMBER 15, 2026
View in Browser »

---

Articles & Tutorials

Projects & Code

Events

---

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

---

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

15 Sep 2026 7:30pm GMT

<strong>Topics covered in this episode:</strong><br> <ul> <li><strong><a href="https://eddie.codes/posts/pandas-should-go-extinct/?featured_on=pythonbytes">Pandas Should Go Extinct</a></strong></li> <li><strong><a href="https://github.com/tylerh111/pydantic-pint?featured_on=pythonbytes">Pydantic-pint puts real-world units in your Pydantic models</a></strong></li> <li><strong><a href="https://belderbos.dev/blog/how-libraries-run-rust-inside-python/?featured_on=pythonbytes">How Libraries Run Rust Inside Python (With PyO3)</a></strong></li> <li><strong><a href="https://aws.amazon.com/blogs/big-data/aws-and-ducklabs-building-the-future-of-analytics-together/?featured_on=pythonbytes">AWS acquires DuckLabs</a></strong></li> <li><strong>Extras</strong></li> <li><strong>Joke</strong></li> </ul><a href='https://www.youtube.com/watch?v=uK_gohaLkbM' style='font-weight: bold;'data-umami-event="Livestream-Past" data-umami-event-episode="496">Watch on YouTube</a><br> <p>Sponsored by <strong>Logfire from Pydantic</strong>: <a href="https://pythonbytes.fm/logfire">pythonbytes.fm/logfire</a></p> <p><strong>Connect with the hosts</strong></p> <ul> <li>Michael: <a href="https://fosstodon.org/@mkennedy">Mastodon</a> / <a href="https://bsky.app/profile/mkennedy.codes?featured_on=pythonbytes">BlueSky</a> / <a href="https://x.com/mkennedy?featured_on=pythonbytes">X</a> / <a href="https://www.linkedin.com/in/mkennedy/?featured_on=pythonbytes">LinkedIn</a></li> <li>Calvin: <a href="https://sixfeetup.social/@calvin?featured_on=pythonbytes">Mastodon</a> / <a href="https://bsky.app/profile/calvinhp.com?featured_on=pythonbytes">BlueSky</a> / <a href="https://x.com/calvinhp?featured_on=pythonbytes">X</a> / <a href="https://www.linkedin.com/in/calvinhp/?featured_on=pythonbytes">LinkedIn</a></li> <li>Show: <a href="https://fosstodon.org/@pythonbytes">Mastodon</a> / <a href="https://bsky.app/profile/pythonbytes.fm">BlueSky</a> / <a href="https://x.com/PythonBytes?featured_on=pythonbytes">X</a></li> </ul> <p>Join us on YouTube at <a href="https://pythonbytes.fm/stream/live"><strong>pythonbytes.fm/live</strong></a> to be part of the audience. Usually <strong>Tuesday at 7am PT</strong>. Older video versions available there too.</p> <p>Finally, if you want an artisanal digest of every week of the show notes in email form? Add your name and email to <a href="https://pythonbytes.fm/friends-of-the-show">our friends of the show list</a>, we'll never share it.</p> <p><strong>Calvin #1: <a href="https://eddie.codes/posts/pandas-should-go-extinct/?featured_on=pythonbytes">Pandas Should Go Extinct</a></strong></p> <ul> <li>Pandas' slowness pushes teams toward "Big Data" tools (Spark, Databricks) they don't actually need - most workloads never hit true Big Data scale</li> <li>Amazon Redshift telemetry: ~95% of tables are under 100GB, ~87% of queries touch 80GB or less - that's "Medium Data," not Big Data</li> <li>Polars and DuckDB fill that gap: single-machine, fast, no cluster required</li> <li>1 Billion Row Challenge benchmark: Pandas took 4m28s vs. Polars 5.04s and DuckDB 5.19s - DuckDB also used 19x less memory</li> <li>On a real-world NYC taxi dataset (3GB parquet), pure DuckDB ran 2x faster than pure Pandas while using a fraction of the RAM</li> <li>Bonus: Apache Arrow lets you pass data between Pandas/Polars/DuckDB with zero copying, so trying them out doesn't mean a full rewrite</li> </ul> <p><strong>Michael #2: <a href="https://github.com/tylerh111/pydantic-pint?featured_on=pythonbytes">Pydantic-pint puts real-world units in your Pydantic models</a></strong></p> <p>Pydantic-pint bridges Pydantic and Pint so models can validate physical quantities like 4m or 12 meters instead of bare floats. Fields annotated with PydanticPintQuantity parse user input, convert between compatible units, and serialize quantities back out as strings. That closes a real gap for anything consuming API payloads, config files, or sensor data with measurements, letting you enforce units at the validation boundary instead of hoping every caller remembered them.</p> <ul> <li>via PyCoder's Weekly newsletter</li> <li>Unit mix-ups have literally crashed spacecraft; now your Pydantic models can refuse them at the door.</li> <li>Annotate a field as Annotated[Quantity, PydanticPintQuantity('km')] and inputs like 12 meters arrive auto-converted to kilometers</li> <li>Validation covers string, numeric, and quantity inputs, and model_dump_json serializes quantities as readable unit strings</li> <li>Installable from PyPI as pydantic-pint, MIT licensed, with docs at <a href="http://pydantic-pint.readthedocs.io/?featured_on=pythonbytes">pydantic-pint.readthedocs.io</a></li> <li>Early-stage solo project at version 0.4, so API stability and maintenance are open questions worth discussing</li> </ul> <p><strong>Calvin #3: <a href="https://belderbos.dev/blog/how-libraries-run-rust-inside-python/?featured_on=pythonbytes">How Libraries Run Rust Inside Python (With PyO3)</a></strong></p> <ul> <li>Pydantic v2's validation core (pydantic-core) is Rust under the hood, built with PyO3 - this post shows how that bridge actually works via a small hand-built JSON parser</li> <li>Four steps to get Rust into Python: write a normal Rust module, annotate with PyO3 macros (#[pyfunction], #[pymodule]), compile/install with maturin, then just import it</li> <li>The parser builds a Rust tree first - Python never touches it until the boundary crossing</li> <li>Key insight: converting the Rust result into Python objects (.into_pyobject) is often the expensive part, not the parsing - 100,000 JSON values means ~100,000 Python objects built after parsing's already done</li> <li>Errors cross the boundary too: Rust's typed errors convert into real Python exceptions (ValueError, FileNotFoundError) via From/?, so callers get clean Python semantics</li> <li>Takeaway for anyone porting Rust in: if you're returning a scalar, don't sweat it; if you're returning a big structure, profile the boundary - that's the real cost, not the algorithm</li> </ul> <p><strong>Michael #4:</strong> <a href="https://aws.amazon.com/blogs/big-data/aws-and-ducklabs-building-the-future-of-analytics-together/?featured_on=pythonbytes">AWS acquires DuckLabs</a></p> <p>Thank you Dylan McConnell.</p> <p>What does this mean for the DuckDB ecosystem?</p> <p><strong>DuckDB</strong> is the open-source in-process analytical SQL engine. MIT licensed. The IP is not owned by any company - it's held by the nonprofit DuckDB Foundation, which was created when the team spun out of CWI Amsterdam. Peter Boncz, the CWI representative on the Foundation board, describes it as the entity that holds all IP of open-source DuckDB.</p> <p><strong>DuckLabs</strong> (<a href="http://ducklabs.com?featured_on=pythonbytes">ducklabs.com</a>) is the company, formerly branded DuckDB Labs. Founded a little over five years ago by Hannes Mühleisen and Mark Raasveldt to give the DuckDB team a stable long-term home, bootstrapped deliberately instead of taking VC, grown to 30+ people in Amsterdam, funded by support and feature-prioritization contracts. It employs the core devs. It does not own DuckDB.</p> <p><strong>DuckLake</strong> is one of three projects DuckLabs builds, what they call the Duck Stack: DuckDB, DuckLake, and Quack. DuckLake is the lakehouse format that puts catalog metadata in a SQL database instead of in files on object storage. Quack is newer - an RPC-style protocol that turns DuckDB into a client-server system where both ends are DuckDB instances, slated to stabilize in DuckDB v2.0 in September 2026.</p> <p><strong>MotherDuck</strong> is a separate Seattle company, Jordan Tigani's, selling serverless hosted DuckDB. It was started in partnership with DuckDB Labs and has worked closely with Hannes and Mark for four years. It contracted DuckLabs for engineering work and contributes heavily upstream - three of its engineers are among the top 10 outside contributors to DuckDB. It also sells its own DuckLake offering. Customer and collaborator, never owner.</p> <p><strong>What the AWS post changes.</strong> Amazon bought the company, not the project. DuckLabs joined AWS effective September 1, with the process concluding August 31, 2026. Hannes and Mark keep leading the team and the project's technical direction, the team stays in Amsterdam, and DuckDB stays MIT under the Foundation. AWS gets the people and a direct line to the roadmap. The license protects your code, not your priorities.</p> <p><strong>Three second-order effects worth tracking</strong>:</p> <p>The Foundation board is the real question. It has three directors: Mühleisen, Raasveldt, and Boncz. Two now work for AWS. Commentary on the deal has focused on exactly this - the license protects the code, not the roadmap. The announced counterweight is governance: a technical advisory board on the Foundation, and opening the extension stack so extensions signed by other developers can run in DuckDB.</p> <p>MotherDuck immediately moved into the business DuckLabs vacated. It now sells DuckDB enterprise support, which it had avoided because it didn't want to compete with DuckLabs' business model, and says it has explicit blessing from Hannes and Mark now that they're joining Amazon. It also bought Tower.dev the day before the AWS announcement.</p> <p>Everyone expects an AWS DuckDB service. Tigani says Amazon will likely release one eventually, and welcomes the competition, citing Redshift's failure to slow Snowflake on AWS. The groundwork is already visible: Amazon Quick uses DuckDB to query S3 Tables and has processed over 2.5B queries with it since launching in October 2025.</p> <p>The DuckLake angle is the one to watch. AWS is heavily committed to Iceberg through S3 Tables, and it just acquired the team behind a competing lakehouse format. The stated plan is to use DuckDB, DuckLake, and Quack together to power a new generation of data services, but which format wins internal priority is unannounced.</p> <p><strong>Extras</strong></p> <p>Calvin:</p> <ul> <li><strong>astral-sh/uv 0.12.12: code-signed release binaries</strong> 🥳</li> </ul> <p>Michael:</p> <ul> <li><a href="https://forums.macrumors.com/threads/apple-releases-firmware-update-for-140w-usb-c-power-adapter.2488672/?featured_on=pythonbytes">My MacBook power supply rebooted to install updates</a> (?!?)</li> <li><a href="https://www.youtube.com/watch?v=kHL3XzjpT5w">The Story of VS Code | Official Documentary</a></li> <li><a href="https://aws.amazon.com/blogs/big-data/aws-and-ducklabs-building-the-future-of-analytics-together/?featured_on=pythonbytes">Amazon/AWS acquires DuckLabs</a> (see recent episode on DuckLake)</li> </ul> <p><strong>Joke: <a href="https://x.com/PR0GRAMMERHUM0R/status/2090076348114985385?featured_on=pythonbytes">We're agentic now</a></strong></p>

15 Sep 2026 3:24pm GMT

We're delighted to announce that DjangoCon Europe 2027 will take place in Innsbruck, Austria, from February 17-21, 2027!

Photo by Nicole Baster on Unsplash

Each year, DjangoCon Europe brings together people from across the Django community to learn, share ideas, contribute, and spend time together. In 2027, that community will come together in Innsbruck for five days of Django, Python, and community.

DjangoCon Europe is organized by community volunteers and has long been one of the highlights of the Django community calendar. Developers, contributors, newcomers, and long-time community members from around the world come together to exchange knowledge, make new connections, and help shape the future of Django.

Save the dates

📅 February 17-21, 2027

📍 Innsbruck, Austria

And there's even more good news: the Call for Proposals is open, and tickets are now on sale!

Submit a proposal

Have something you'd like to share with the Django community? The Call for Proposals is open.

Whether you have a deep technical topic, a lesson you've learned from building with Django, an idea that could benefit the community, or something completely unexpected, we'd love to hear from you.

Submit a proposal →

Get your ticket

Ready to join us in Innsbruck?

Tickets for DjangoCon Europe 2027 are now on sale.

Come spend five days learning, sharing, meeting fellow Djangonauts, and enjoying everything the Django community has to offer.

Get your ticket →

Volunteer at DjangoCon Europe

DjangoCon Europe is a community-run conference, and volunteers play an important part in making it happen.

If you'd like to help us make DjangoCon Europe 2027 a great experience for everyone, sign up to volunteer. Whether you're a long-time member of the community or attending your first DjangoCon, we'd love to have you involved.

Sign up to volunteer →

Sponsor DjangoCon Europe

Support the conference financially and gain visibility in the Django community.

Learn more about sponsorship →

Download the sponsorship brochure →

Email the sponsorship team →

There's plenty more to come as we get closer to the conference. Keep an eye on the DjangoCon Europe 2027 website for the latest news and updates:

Visit the DjangoCon Europe 2027 website →

See you in Innsbruck in 2027! 🇦🇹

15 Sep 2026 1:20pm GMT

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

15 Sep 2026 10:00am GMT

---

News

PyCharm & Django Fundraiser Extended to September 14

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

Call for volunteers: Fundraising Working Group

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

---

Django Software Foundation

Django Steering Council Meetings - 2026

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

---

Python Software Foundation

Incident Report: File Hosting Errors

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

---

Wagtail CMS News

Prototyping a new CLI for Wagtail

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

---

Updates to Django

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

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

News in Django 6.1:

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

News in Django 6.2:

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

---

Django Fellow Reports

Django Fellow Report - Jacob

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

Django Fellow Report - Sarah

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

Django Fellow Report - Natalia

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

---

Sponsored

Your task ran before the transaction committed.

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

---

Articles

Soft-deprecating re.match()

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

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

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

Nifty Django Feature: Q() Objects

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

---

DjangoCon US Recaps

I Think That Feeling is Called Hope - Rachell Calhoun

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

TSBT73: Pumpkin Spice Bytes - Velda Kiara

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

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

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

DjangoCon US 2026 | Chicago - Jon Gould

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

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

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

---

Django Job Board

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

🆕 Machine Learning Engineer (Hybrid) at Provision

Django Developer at The Cruise Brothers

Full Stack Software Engineer (Hybrid) at Provision

---

Projects

gettranslatebot/translatebot-django

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

lincolnloop/django-absurd

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

11 Sep 2026 3:00pm GMT

Weeknotes (2026 week 37)

Tonight the temperature will drop to 10°C. I like it when it's hot, but now I really enjoy the slightly cooler temperatures in Europe. The last post was written in the middle of the heat wave. Yesterday we still had temperatures of over 30°C, which is a lot for September. But it will be the new normal. Next year probably won't be cooler.

Releases from the last four weeks

Lots of activity!

django-authlib

django-authlib 0.19 hardens the OAuth2 implementation a bit against replay attacks, provides utilities for removing password logins from the Django administration interface, and removes some of the confusion around role-based permissions. Upgrading is recommended.

django-content-editor

django-content-editor 9.0.2 fixes a bug in the function which allows cloning plugins from other regions. The bug was most visible when using something like django-json-schema-editor's plugins which are only proxy models. Their type was lost because I was using _base_manager, which didn't do the downcasting properly. (Sorry for the word salad.)

django-tree-queries

django-tree-queries 0.26.1 now uses annotations instead of .extra() to add the tree_path and tree_depth fields. This is great because the ORM knows these fields properly and we can now use e.g. .filter(tree_depth=1) instead of .extra(where=["..."]).

This change was mainly motivated by the renewed interest in deprecating .extra() at some unknown future point in time.

django-debug-toolbar

django-debug-toolbar 8.0 ships a new design! I again didn't contribute a lot, but I'm very proud that we were able to ship this as a team.

feincms3

feincms3 6.0.2 ships new utilities and, most importantly, fixes crashes when passing %00 to the root middleware. Using null bytes when comparing text field values on PostgreSQL leads to crashes. These are mostly an annoyance without data exposure, but definitely worth fixing.

The reason for the major version bump is that we finally dropped support for Django 3.2. That's the only breaking change, so upgrading should be easy for everyone.

django-js-asset

django-js-asset 4.1 fixes issues around lazy CSP nonce handling as well as the same issue Django itself had around rendering HTML-safe strings.

django-prose-editor

django-prose-editor 0.27.2 adds a default menu item for the code block extension and updates ProseMirror and Tiptap. It also adapts to the changed CSS of the Django 6.1 administration interface.

django-json-schema-editor

django-json-schema-editor 0.14.1 includes a fix for saving JSON schema fields when the schema doesn't contain any properties, plus fixes for the Django 6.1 admin CSS.

django-admin-ordering

django-admin-ordering 0.21 now activates orderables properly when the same model was orderable both in the change list and in the change form. I developed the fix for this in early 2025 but never released it. It's what happens.

feincms3-cookiecontrol

feincms3-cookiecontrol 1.7.2 includes bugfixes for edge cases while bringing down the byte count for the cookie banner and media embedding script from 3961 (in 1.7.1) to 3909 bytes.

feincms3-data

feincms3-data 0.11.1 brings fixes for handling unique fields when the same unique value is removed and then re-added with a different primary key.

django-translated-fields

django-translated-fields 0.14 contains no relevant code changes to the module itself at all. It was just time to release a new version more than two years after the last release to show that the project is still active and update the Trove classifiers.

09 Sep 2026 5: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