fidzu : python

Learn the fundamental principles behind OOP and how they connect to the syntax of Python.

Introduction

Welcome! This article will teach you the core ideas behind object-oriented programming, commonly known as OOP. This is the article I wish I read many years ago, when I was first learning about OOP in Python.

If you're new to OOP, this article will explain why OOP exists, how it works, and how to work with OOP in Python. If you think you already know OOP, this article will change the way you think about programming and Python.

Code is about real-world things

Let me tell you about a programming project I had to do in college where you had to write a library management service. We were expected to work in pairs and I was paired with my good friend Tito.

Tito and I sat down and started going through the problem statement, figuring out what we needed to implement. We got to a point where Tito turned to me and said:

"It's not obvious to me what's the best way to represent a book in our program. Maybe you can start implementing the search functionality and I'll think about this for a while."

The search functionality was a set of functions that the problem statement required us to implement:

• find_by_title(catalog, search_term): returns a sublist with the books whose title contains the given search term
• find_by_genre(catalog, genre): returns a sublist with the books of the given genre
• find_by_author(catalog, author): returns a sublist with the books written by the given author

I nodded, but then I thought about it for a second. If I don't know anything about how to work with books, there's no way I can implement these three functions. Tito agreed with me and told me he'd provide me with these functions:

• book_title(book): returns the title of the given book
• book_genre(book): returns the genre of the given book
• book_author(book): returns the author of the given book

He told me to think of these functions as auxiliary functions that he would implement. I didn't have them yet, but I could write my search functions trusting he'd implement them correctly.

Now, think about it for a second. Can you implement the functions find_by_title, find_by_genre, and find_by_author, using the auxiliary functions that Tito will implement? How would you go about it?

I worked on it for a bit, and eventually used a list comprehension to define the function find_by_title:

def find_by_title(catalog, search_term):
    search_term = search_term.casefold()
    return [
        book
        for book in catalog
        if search_term in book_title(book).casefold()
    ]

The function find_by_title goes through the list of books called catalog with a loop and uses the auxiliary function book_title to retrieve the title. It then uses casefold to perform a case-insensitive search.

Something worth...

26 Aug 2026 2:01pm GMT

As someone who teaches Python programming for a living, I've spent the last few years wrestling with the educational implications of AI. I'm changing everything I do to adjust to our new AI reality, experimenting with new ideas, including my AI-based Socratic tutor (https://practice.lernerpython.com/). I keep what works, throw away what doesn't, and then try the next thing. I've never been more challenged as a business owner. And yet, I've never been more excited about being an instructor.

What about universities? I've said for a while that they'll also need to change, but that they cannot do so nearly as quickly as I can. They're big and bureaucratic, and have to answer to donors, staff members, students, parents, and governments. It'll take years for them to figure out what they want to do, and how to do it.

And then, last night, I received e-mail from Sally Kornbluth, the president of MIT, with a message addressed to all MIT students, faculty, staff, and alumni. The subject, "AI and education: A watershed moment for MIT," was quite the understatement.

Kornbluth announced a report from an ad-hoc committee on AI in education (https://aiandeducation.mit.edu/report/). It's the clearest, deepest, and most profound take I've yet read on the subject. It doesn't hold back, spelling out the good and the bad. I'm still absorbing the full impact of what they wrote - and they wrote a lot. But the report - which I expect will be given formal backing in the near future - has, more or less, called for a complete revolution in how instruction works. And they're willing to take the lead in trying new approaches, technologies, and assessments, both for their own future and for the future of university education.

Maybe a university can't change as quickly as my one-person business. But the report sounds urgent and focused, and I think we should expect MIT to change as quickly as any large organization can. The report even recognizes the slow pace at which curricular changes are normally made, and encourages departments to allow for curricular experimentation without onerous bureaucracy.

Among the many smart, important points they make:

• Classes are going to change. Instructors will need to re-assess what people need to get out of a course, and think about how AI can be integrated into it. Whether that means developing new course-specific tools or having students use AI to advance their knowledge and understanding will depend on the course and the instructor. But they are actively encouraging instructors to think deeply about what they are really trying to teach, and what tools might help them to achieve that more easily.
• Embracing apprenticeship. You could argue that graduate school (and to a lesser degree, undergraduate studies) are already an apprenticeship program, in which aspiring researchers learn from their more experienced professors and peers. AI threatens this model to some degree, enticing researchers to use agents to accomplish a task, rather than bringing on someone who might take longer or make mistakes. As they say in their report, "Using research as an opportunity for learning-by-doing may produce seeming 'inefficiencies,' but that's a feature, not a bug." Struggling and working through problems is an inherent part of the learning process.
• Education is about the process of learning. I keep meeting people (students and professionals) who say that they ask AI to write papers and essays for them, because they "know it anyway," and this is just a faster way of producing the same text they would have written on their own. This is, of course, nonsense - as the saying goes, "writing is thinking," and anyone who writes knows that as you struggle over how best to make your argument, you're learning more than any classroom could teach. As the report says: "Getting the right answer from a chatbot can create the illusion of learning - but it can also trigger 'cognitive surrender', where students fall back on AI at the first hint of struggle." They similarly say, "All of us who teach at MIT will need to be prepared to help students understand both that the process of education is necessarily a productive struggle, and that the most important product of their education is not a GPA or a diploma but themselves: their personal growth and intellectual maturity and the development of their own imagination, insight, and judgment."
• Assessment will need to change. The report says, "MIT should take this opportunity to consider what role grades play in our overall system, and if the current approach could be improved." The old standards of homework assignments and exams might not be the best ways to know whether a student has really mastered the material. I've been saying for a while that it might be time to bring back oral exams, either alone or alongside project-based learning. The report discourages the use of AI detectors, which have a history of being unreliable and discriminatory. Plus, "stepping up 'policing' around AI use builds an adversarial atmosphere of distrust between instructors and students, which understandably hurts students' motivation and morale."
• Constructionism has its moment? I feel like this is a moment in which all of the educators who spoke of project-based, constructivist, and constructionist approaches for decades might finally have their moment in the sun. The report points to the potential for individualized attention and instruction that AI can uniquely provide - and which would go hand-in-hand with the project-based approach. Seymour Papert developed constructionism at MIT, calling for a revolution in education around personalized, project-based, technological learning. I'm an MIT alumnus, a constructionist at heart, and I did my PhD in learning sciences under one of Papert's students. So watching Papert's own institution consider a revamp of education around his principles is, for me, delicious.
• Ethics are crucial. We're now in an era where anyone can generate a decent-sounding article within minutes. The report emphasizes that a culture of transparency around the use of AI is and will continue to play a critical role. This is true not just for students, but also for instructors and researchers, who will be expected to clearly state where and how they used AI in their work. The report says, and I believe rightly so, that using AI is just fine - but you need to be specific about how you use it, and what you did with it. They also point to the need for equitable access to AI, ensuring that all members of the MIT community can use this technology, not just those who can most easily afford it.

The report also emphasizes, repeatedly, the importance of human interactions in all of this. AI, more even than phones and the Internet, has a tendency to push people to hole up by themselves, rather than interact with others. (The report points to fewer in-person study groups, and a drop in the number of students coming to office hours.) And it is those interactions that are not only at the heart of research, science, and learning, but of human existence. They stress the need for incorporating "social learning" into projects, and to encourage people to work together. As they say, "Instructors should intentionally structure such interactions to achieve desired learning objectives and maintain quality, even in large classes."

This report isn't the last word on AI and education, and it isn't meant to be. A year from now, we'll probably see parts that were prescient, and other parts that were misguided (if well meaning). But it's the first time I've seen a major university announce a plan to reshape the entire university's educational approach around our new reality. This is an ad-hoc committee, and thus doesn't have any official standing. But the fact that MIT's president sent it out to every member of the MIT community tells me that this is way beyond a simple committee. I expect that MIT will put serious effort (and money) behind the changes needed to see these things through.

If you're an educator, then you owe it to yourself, and to your students, to read this report. And then to re-assess what you do, starting with the principles that MIT is using to evaluate itself, as the first stage of what'll likely be a revolutionary transformation.

The post MIT just called for an educational revolution appeared first on LernerPython.

26 Aug 2026 12:14pm GMT

<strong>Topics covered in this episode:</strong><br> <ul> <li><strong><a href="https://github.com/chr0nzz/traefik-manager?featured_on=pythonbytes">Web UIs for your reverse proxy</a></strong></li> <li><strong>Wagtail 8.0 is hot off the presses</strong></li> <li><strong>RISC-V is now officially supported by CPython</strong></li> <li><strong><a href="https://www.djangoproject.com/weblog/2026/aug/10/annual-release-cycle?featured_on=pythonbytes">Django's annual releases make every version an LTS</a></strong></li> <li><strong>Extras</strong></li> <li><strong>Joke</strong></li> </ul><a href='https://www.youtube.com/watch?v=_hmos9eMyDY' style='font-weight: bold;'data-umami-event="Livestream-Past" data-umami-event-episode="493">Watch on YouTube</a><br> <p><strong>About the show</strong></p> <p>Sponsored by <strong>Logfire from Pydantic</strong>: <a href="https://pythonbytes.fm/logfire">pythonbytes.fm/logfire</a> <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> 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. Finally, if you want an artisanal, hand-crafted 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.</li> </ul> <p><strong>Michael #1: <a href="https://github.com/chr0nzz/traefik-manager?featured_on=pythonbytes">Web UIs for your reverse proxy</a></strong></p> <p>Traefik, nginx, and Caddy all sit in front of a lot of self-hosted infrastructure, and all three are configured by hand-editing files. Three active projects put a control plane on top: <a href="https://github.com/chr0nzz/traefik-manager?featured_on=pythonbytes">Traefik Manager</a> (Python + Flask), <a href="https://github.com/0xJacky/nginx-ui?featured_on=pythonbytes">Nginx UI</a> (Go + Vue), and <a href="https://github.com/zackwag/caddy-ui?featured_on=pythonbytes">caddy/ui</a> (React + Node). All three are additive rather than replacements - none of them take ownership of your config away from you - which is the part that matters when the thing has write access to production routing.</p> <ul> <li><strong>Traefik Manager</strong> is the Python one: Flask 3.1 and Gunicorn for the control plane, a lightweight Go agent for remote instances, currently v1.10.0 with an Android companion app.</li> <li><strong>Nginx UI</strong> is a single Go binary at 11.3k stars, with a block-style config editor, an Ace editor doing LLM completion on nginx syntax, and an MCP server so agents can drive it.</li> <li><strong>caddy/ui</strong> runs as two containers next to your existing Caddy, reads and writes your Caddyfile directly, and uses Caddy's <code>/adapt</code> API to validate before reload - no Docker socket required.</li> <li>Each one edits the config the underlying server already reads, so your files stay the source of truth and you can drop the UI without unwinding anything.</li> <li>Undo is a first-class feature across all three - timestamped backups with optional Git history, config version compare and restore, Caddyfile snapshots with one-click rollback.</li> <li>Observability is where they diverge: Traefik Manager does CrowdSec and a visual route map, Nginx UI does server metrics, caddy/ui streams access logs over SSE and pulls p50/p95/p99 off Caddy's Prometheus endpoint.</li> <li>Maturity spread is wide - Nginx UI has 11.3k stars, caddy/ui has 4 and was built in a single Claude session - and caddy/ui ships with auth off by default, so set <code>CADDY_UI_USER</code> and <code>JWT_SECRET</code> before it goes anywhere near a public interface.</li> </ul> <p><strong>Calvin #2: Wagtail 8.0 is hot off the presses</strong></p> <p>Link: https://github.com/wagtail/wagtail/releases/tag/v8.0</p> <ul> <li>Custom base page models are now supported, so projects aren't locked into subclassing Wagtail's Page as shipped (Matt Westcott).</li> <li>New v3 REST API handles both read and write CMS operations, a first for Wagtail's API.</li> <li>A global registry for permission policies, plus full customizability for the remaining page views via PageViewSet.</li> <li>AVIF and WebP images are no longer auto-converted to PNG by default, a real behavior change to watch on upgrade.</li> <li>Five security fixes: page admin API restrictions, document identification by SHA1 hash, descendant collections in the Documents/Images API, snippet copy permissions, and the page translation endpoint.</li> <li>Formalized Django 6.1 support, and CI now runs on uv with a lockfile.</li> </ul> <p><strong>Sponsor</strong>: <a href="https://pythonbytes.fm/logfire">Logfire from Pydantic</a></p> <p>Your AI agent failed at 2am. Was it the model? A tool call? The database? Most observability tools can't tell you, because they only see part of your stack. Pydantic Logfire sees all of it. One trace across your agents, LLMs, APIs, and database. Down to the infrastructure: services, Kubernetes, and hosts. It's built on OpenTelemetry, with SDKs for Python, TypeScript, and Rust, and it works with any OTel-compatible language. Every prompt, token count, and cost, right next to your vector searches and API calls. You query everything with Postgres-compatible SQL. And so can your coding agent, through the Logfire MCP server. Stop guessing. Read the trace. Pydantic Logfire. AI, it's still just engineering. Visit <a href="http://pythonbytes.fm/logfire">pythonbytes.fm/logfire</a> today and sign up today. Get 10M records free every month, no card required. You can even click "Onboard with your coding agent" to copy a prompt to have claude or codex integrate Logfire into your app. Thanks to Pydantic for supporting the show.</p> <p><strong>Calvin #3: RISC-V is now officially supported by CPython</strong></p> <p>Link: https://blog.python.org/2026/08/riscv-now-officially-supported/</p> <ul> <li>CPython added RISC-V as a tier 3 platform under PEP 11, specifically the 64-bit Linux target riscv64-unknown-linux-gnu.</li> <li>RISC-V is an open ISA anyone can implement, unlike x86 and ARM, and its market is projected to quadruple by 2032.</li> <li>The RISE Project donated real RISC-V machines for buildbots; the author's work was funded by a Sovereign Tech Agency fellowship.</li> <li>What changes: the port is now a maintained compatibility target, so CPython changes are less likely to quietly break it. What doesn't: no <a href="http://python.org/?featured_on=pythonbytes">python.org</a> installers, no binary wheel parity for native extensions.</li> <li>Next up: RISC-V runners in CPython CI for pre-merge feedback, then a push toward tier 2, plus architecture-specific optimizations.</li> <li>The ask is testing. If you have RISC-V hardware, build CPython, run your test suite, file what breaks. Tier 3 is the weakest support tier. PEP 11 tier 3 requires a core developer contact and a buildbot, but failures on tier 3 platforms explicitly do not block a release. Saying "ongoing CI/testing expectations" oversells it. The honest bit is "someone is now on the hook for it, and breakage gets noticed," not "it's guaranteed working." Worth the caveat that this is Linux SBCs, not microcontrollers. A VisionFive 2 counts, an ESP32-C6 or Pico 2 does not. Those are 32-bit non-Linux parts where MicroPython is still the answer.</li> </ul> <p><strong>Michael #4: <a href="https://www.djangoproject.com/weblog/2026/aug/10/annual-release-cycle?featured_on=pythonbytes">Django's annual releases make every version an LTS</a></strong></p> <p>Starting with Django 2028, Django will move to one January feature release per year, adopt calendar-based version numbers, and support every release for three years. The old distinction between standard and LTS releases disappears, giving teams a predictable annual upgrade path that aligns more closely with Python's own release and support cadence.</p> <ul> <li>Every Django release becomes the safe, long-supported choice, so teams no longer need to wait for a specially designated LTS version or absorb two years of changes at once.</li> <li>Each release gets one year of mainstream bug fixes followed by two years of security and data-loss fixes.</li> <li>New releases support the three latest Python versions and add the next Python release during their first year.</li> <li>Calendar versioning begins with Django 2028, followed by Django 2029 and so on.</li> <li>Three Django versions will be supported at any time, giving third-party packages a clearer rolling target.</li> <li>Nothing changes before 2028, and existing commitments for Django 5.2 LTS and 6.2 LTS remain in place.</li> </ul> <p><strong>Extras</strong></p> <p>Calvin:</p> <ul> <li>The Python docs now document the time complexity of built-in types https://docs.python.org/3.16/library/time-complexity.html</li> <li>Thinking in Python - Bruce Eckel's free book https://thinkinginpython.com/ Michael:</li> <li><a href="https://gist.github.com/mikeckennedy/2f45134b3281b3ccf2729e3a7c21ea4f?featured_on=pythonbytes">prune_uv_pythons.py</a> - Prune uv-managed Python installs, keeping only the newest patch per minor version <ul> <li>Runs automatically in my system "upgrade" script: <a href="https://blobs.pythonbytes.fm/upgrade-output-2026.png?cache_id=96100e">upgrade-output-2026.png</a></li> </ul></li> <li>Started using <a href="https://ollama.com/search?c=cloud&featured_on=pythonbytes">Ollama cloud models</a> for my Hermes assistant. Thanks to Jeff Triplett I learned they are not just local models.</li> </ul> <p><strong>Joke: <a href="https://www.talisman.org/tao/?featured_on=pythonbytes">The Tao of Programming</a> -</strong> Book Seven: Corporate Wisdom</p>

26 Aug 2026 1:07am GMT

When I read consistent, cohesive code, I have a feel for its author. I may disagree with the ideas, but I can feel where the author is driving it. Other times the feel is split-brain - the code's "energy" is fractured, the work of unaligned hands each solving its own small problem, none with an idea where the whole is going. Immediately I feel it should be rewritten or refactored holistically.

Here is the paradox. Most of us are dedicated professionals with years of experience, and bad code is everywhere. Programmers I respect produce it; my own code is far from perfect. Why?

25 Aug 2026 10:00am GMT

🔗 Links

• 2026 Django Developers Survey Results
• Django 6.1 release notes
• Talk Python #446: Updates on Django's Async Story with Carlton
• Choose Boring Technology

🎥 YouTube

• YouTube Channel: @djangochat

24 Aug 2026 5:32pm GMT

Python is a perfect language for Agile development, where requirements might change on the go. Especially if you are in a startup business, you will need to experiment and change things fast. However, Python is an interpreted language, and in certain situations you might need faster performance than what an interpreted language can provide. A common practice in these cases is using python-to-binary bindings, where the binary code is built with Rust, C++, or Go. In this article, I will explore bindings to Rust-based code.

How do the bindings work

The idea behind bindings is that you create a module with functions of a specific domain in a language that compiles to binary, and build it as a C-compatible dynamic library (.so on Linux, .dylib on macOS, .dll on Windows). Then a Python wrapper is built as a Python package and installed together with the dynamic library, allowing you to import and use functions that pass control to the corresponding functions in the dynamic library. On some occasions, classes can be used instead of functions. If any parameters are complex, they must be serialized in the wrapper and passed to the dynamic library as a JSON string or as a set of individual primitive parameters.

An experiment with benchmarks

To try this Python-Rust communication, I vibe coded an experiment that reads a large CSV file and builds a new one with duplicates stripped out based on specified column indexes. In my test case, it was a 3 MB CSV file with data about European NGOs for the donation platform I am building, where I wanted to remove the NGOs that don't have website URLs listed. As benchmarked, the file was processed 4.3x faster with the Rust binding than directly with Python.

Here is the repo to get a first glimpse into the code and structure.

What is there to know about Rust

A few things about Rust: Rust packages are built with Cargo, which is the equivalent of pip, virtualenv, and setuptools combined. A single package is called a crate, and it can be published to crates.io, the equivalent of PyPI. To create a Python-to-Rust binding, the standard approach is to use Rust's PyO3 library together with maturin, a build tool installable as a PyPI package.

Rust syntax is not the most developer-friendly compared to Python or Go, but with today's AI agents, most Python-native code can be ported to it fairly easily. The good thing about Rust and Go compared to C++ is that you don't have to manage memory at a low level or work with pointers directly.

The package structure

The common file structure can be:

thepackage_rs/           # the package - self-contained and installable
├── Cargo.toml           # crate manifest (pyo3, etc.)
├── pyproject.toml       # maturin build backend config
├── src/lib.rs           # Rust implementation
└── python/
    └── thepackage_rs/
        └── __init__.py  # Python wrapper

Once the code is ready, you build it with:

(.venv) maturin develop --release

This builds the Python package and installs it into the current virtual environment. You can also get the wheel at thepackage_rs/target/*.whl, built for your specific operating system.

Rust in Django

When developing Django websites, the biggest bottlenecks are usually not in the language itself, but in the connections to databases, file systems or object storage, and APIs. Still, in cases where you need to process large amounts of data or do heavier calculations, using a binary instead of Python makes sense. The orjson library, and DRF renderers built on top of it such as django-orjson or drf-orjson-renderer, are good examples of this - Rust boosts the speed of building or parsing JSON 2-10x compared to a Python-native implementation. The best places to use Rust replacements are background tasks, management commands, template parsing (see the experimental django-rusty-templates), and occasionally views or middleware.

Final words

So Python itself is good enough, especially when it comes to code readability and speed of development. However, when needed, certain parts can be improved 2 to 10x just by rewriting them as Python-Rust bindings. Just keep in mind that when it comes to views with data from the database or Elasticsearch, post-processing - such as reordering in Python or Rust - is an antipattern; do that directly in the queries instead. Finally, keep in mind, that building with Rust will need extra dependencies and maintainance in your workflows.

Cover photo by Alex Tepetidis

23 Aug 2026 5:00pm GMT

Starting with 0.3.0, Astral's uv brought many great features, including support for cross-platform lock files uv.lock. Together with subsequent fixes, it has become Python's finest workflow tool for my (non-scientific) use cases. Here's how I build production-ready containers, as fast as possible.

06 Aug 2026 12:00am GMT

As I have discussed in previous posts, "AIs" can make mistakes. In fact, they do make mistakes, and their mistake-making patterns are such that where and how they will make mistakes is both uncertain and constantly changing.

Thus, in any scenario where you want to attempt to make "productive" use of "AI", you must have a system in place for checking every result. Not checking some results; checking every result. If each result might have a consequence for you (and if it didn't have a consequence, why bother automating it?) and you cannot predict in advance which kinds of results will need verification, then verification is always required.

The verification often ends up being just as expensive as doing the work in the first place, which means that if you want your usage of "AI" to be personally profitable, you have to find someone else to externalize the cost of verification onto. This person becomes your adversary, and, if you are successful, your "AI's" victim.

The Ladder-Climber And Their Reverse-Centaur Rungs

One way that this constellation of facts can straightforwardly assemble themselves into a dystopian nightmare is the phenomenon, described by Cory Doctorow, of the reverse centaur. This is when your employer non-consensually turns you into the verification system. The "AI" does the fun part of initially performing the work, and then you do the boring part where you check if the robot is right and clean up its messes, even if everyone already knows that it would, in aggregate, be cheaper for you to do the work in the first place.

Reverse centaurs can be made from any automation, not only "AI" automation. I think that there is a reason that this term happens to have emerged in the "age of AI", though, and not with earlier automation technologies (even those which were considerably more viscerally horrific). That reason is: the wrongness of "AI" output is not merely a technical feature that must be compensated for, it is a generalized externality.

As I mentioned above, if you are responsible for the entirety of the work, both extruding the "AI" output and checking it, it's usually cheaper to have humans do the entirety of the work to begin with. When humans do the writing directly, we can check as we go, and thus verification doesn't need to be as comprehensive.

When "AI" coding advocates say "code review is the bottleneck", what they are observing is that the LLM is still rolling the dice for each PR, and a human is still necessary to verify that each of those rolls is a winner. But calling this process "code review" is a bit of a misnomer; it's not really "code review" in the traditional sense, it's human understanding.

Before the advent of "AI", the human understanding was implicit in the process of writing the code in the first place¹, and the code review was a way of diffusing and extending that understanding. Now that the code can be authored with no initial understanding taking place, that cost has not gone away, it has moved.

Human understanding was always the bottleneck.

However, this is taking a collaborative view of a software project, where satisfying the needs and solving the problems of your customers are the goals. We can see that "AI" is a bad tool to satisfy those goals, because all it's doing is converting the first half of the work, that of understanding the code as you write it, to understanding the agent's output as you read it.

What if, instead, we were to take the view that every software company is a Hobbesian nightmare, red in tooth and claw? In this view, the only goal of a software project is for the individual developers to make their promo cycles and get their bonuses. Given that there is only a certain amount of money to go around, this is a zero-sum game where each programmer wants to look more productive than their colleagues.

Pretty much every organization finds it easy to reward "productivity" as expressed by lines of code emitted, but the benefits of doing thorough and thoughtful design, analysis, and code review very difficult to reward. In this world, an LLM is an invaluable tool for the sociopathic ladder-climber, particularly if your legacy organization is still structuring their workflows as if the person prompting the bot is "writing" the code, and then they get to foist off the act of "reviewing" the code onto someone else.

Here, the prompter effectively externalizes the cost of the LLM's failures but internalizes any benefits. The prompter will vibe-code a big feature, so large that the assigned reviewer can't possibly comprehend it all effectively. When this happens, the reviewer will, eventually, be pressured to approve it, even if they can try to spot a few problems along the way. The reviewer has their own work to get back to, after all, the obligation to review the prompter's (read: the bot's) code is a drain on their time that they are not going to get rewarded for.

If this feature is a big success, the prompter gets a promotion. If it causes a big issue, well, the reviewer must not have been careful enough.

This is why LLMs are "good for coding", and also why their biggest promoters keep having outages.

The Generative Gish Galloper

Coding is the biggest "success story" of this type of adversarial communication, but it is by far not the only instance of such a thing. LLMs create a new form of leverage that can turn Brandolini's law from a linear advantage into an exponential one. If you are engaged in a political debate where you want to overwhelm the other side in nonsense, an LLM can generate bullshit faster than it is physically possible for a human being to type, let alone respond thoughtfully. There is an asymmetry to the utility of this weapon as well: only one side of the political spectrum wants to flood the zone and destroy trust in institutions and the concept of truth. There's a good reason that the fascists love it.

Straightforward Spam and Fraud

This is kind of obvious, but LLMs can generate lightly-customized, plausible-looking text much more quickly than any human being. This facilitates their use in fraud, spam, and scams. In a spamming or fraudulent interaction, once again, the costs are externalized onto the victim: the recipient of a spam message has to do all the work of "checking" the LLM's output. Spammers already expect very low hit rates from boilerplate, and if the LLM can increase those percentages from 1% to 5% the technology will pay for itself; they don't need anything like reliable accuracy.

Customer "Support"

If you have any kind of commercial relationship with a company, I probably don't even need to mention this: customer "support" bots are a misery. Everybody knows it at this point. But customer support is usually conceptualized by businesses as an adversarial interaction, because it is a cost center. They maintain internal metrics on time-to-resolution and try to optimize them. Implicitly, this creates a dynamic where the goal of the customer service agent's job is not to solve your problem, but to emit noise that will cause you to think your problem is resolved, or to give up, as fast as possible. Unsurprisingly, LLMs can emit this noise faster than humans can, getting those customers off the phone. But those customers will remember those interactions, and the story outside the TTR metrics is horrible.

Similarly to the situation in software development, LLMs can look very good on paper for customer support, but mostly what they are doing is illuminating the problems with the industry's existing metrics, by turning "winning the metrics battle against the customer" into a more obvious and immediate defeat for the company's long term reputation.

"Education"

In 2026 it is sadly a fact of life that students cheat all the time using "AI", and that this cheating is very successful, in that the teachers find it very hard to detect.

LLMs are great for cheating on schoolwork because the student is externalizing the work of the checking onto the teachers, who are often starting at a disadvantage to begin with, at least in the US.

My view is that this is happening because of a divergence in the way that students vs. teachers (or, more accurately, "the broader educational system") view grading.

When a student is asked to write an essay, the teachers see the effort as both intrinsically worthwhile for the student, as well as useful as a pedagogical tool to evaluate and react to the student's progress. The student, by contrast, sees a stumbling block designed to knock them off the path to success and into a permanent underclass. It is no wonder that the student sees "AI" as useful to their own goals and has no compunction about deploying it.

There is a bitter irony that the ability to understand the inherent value of actually writing the essay on their own is the sort of thing that students can really only learn by writing a bunch of essays. There's no way that I can think of which makes the benefit legible as long as a shortcut is available.

The net effect here is a downward spiral, where the already-wobbling educational system is sustaining an attack that it doesn't have the resources to recover from. The individual students' attacks against their teachers and their schools' grading systems might appear to momentarily succeed, but they will win the battle and lose the war.

Spamming "For Good"?

Usually when we talk about someone unilaterally choosing to enter into an adversarial relationship, that's an "attack" and for good reasons we have a negative impression of the attacker. However, I would be remiss if I did not point out that there are some cases where the relationship was already adversarial; just because you're the attacker doesn't mean that you are evil.

For example we might imagine use-cases like automatically filing appeals for prior authorizations against health insurance. It's relatively well-known at this point that the main way for-profit insurers maintain their margins is by denying claims right up to the line of the policies themselves being fraud, so using a spamming tool to fight them might be entirely justifiable² in that case.

Similarly, using an LLM could be justified in a fight against a company refusing to honor a warranty. One could imagine using an LLM to immediately generate replies and escalations.

However, even in imagined cases like these, the underlying problem is that the insurers and the vendors already have a tremendous amount of structural power, so it is more likely that they will have the advantage in deploying a communications weapon like an LLM, as well as enacting policies to simply ignore any LLM-based communication that you might submit. Worse, if these strategies were to become widespread, they might provide an excuse to reject any communications by feeding them into an unreliable "LLM detector" and issuing an automated "computer says no" even to hand-written correspondence.

It is also worth stressing that these cases are imagined, as compared to the very real coworker-abuse, spam, scam, fraud, and disinformation campaigns being waged in real life today.

Therefore, while legitimate uses might exist, it's hard to imagine that there's anywhere they would be genuinely valuable and sustainable. In the best case "AI" will provide a temporary advantage for underdogs that will provoke an arms race which the resource-advantaged adversaries will win in the long run, in the worst case the arms race itself will cement permanent structural change that will make things worse.

"Search" By Stealing

Most of the adversarial utility of "AI" is on the "write" side, since write-amplification is more obviously aggressive than reading. But the "read" side of LLMs - summarization and question-answering - can be a form of attack as well.

To begin with, the act of reading itself is currently enormously destructive, but that's arguably not a fundamental aspect of this technology. They could set reasonable rate-limits and respect things like robots.txt, as search engines have for decades now. They could also refrain from committing criminal levels of copyright infringement. But, today, using "AI" tools does suborn this sort of out-of-control crawling.

More insidiously, consider the scenario described in this YouTube video. The LTT Bros decided to try Linux again, and in the course of so doing, they had problems. When trying to solve these problems, they were faced with a choice: they could consult Reddit, or they could ask an LLM. Asking an LLM would "gaslight the heck out of" them, but they still found it preferable, because they would at least get an answer without getting yelled at.

Initially this sounds great. But it also means that you want to extract knowledge from a community, while mechanically eliding any values or norms that the community may want to impart as part of offering that knowledge. As someone who spent many years in a community tech support role, this is worrying. Many requests for support are people asking how to do things that will momentarily solve a superficial problem but create a long-term reliability problem or even an immediate security risk, that the question-asker doesn't want to hear about. Consider the question "I'm tired of entering my password so much, how do I make it so my laptop unlocks automatically". An obsequious chatbot will helpfully tell you how to do this without pushback.

But, this is also a sort of ethically murky area. The Linux community is somewhat famously, for many years now, a toxic cesspool of general hostility, misogyny, etc. It is certainly a good thing that people can get access to this knowledge without subjecting themselves to abuse. But it also means that the people with the power and the privilege to change the community for the better can just quietly withdraw, rather than fixing the problems. It also means that the positive elements of culture cannot be transmitted, and people will have no opportunity to learn about unknown unknowns.

In this case, the "adversarial" communication is with society. The thing that using an LLM for search lets you do is withdraw from society and avoid forming any personal connections. There are some personal connections which are painful and annoying, and so that can feel like a momentary balm. But the need to make connections in general is, like, the concept of society itself.

Who Am I Hurting?

LLMs are good at adversarial communication. They are so good at it, relative to their other benefits, that they will tend to make communications adversarial if you are not remaining vigilant about the possibility that it might do so. My request to you, dear reader, if you are going to use such tools, is to always ask yourself, "who might I be hurting, if I use an LLM for this?"

If you're using an "AI", who is its adversary? If you haven't given it one yet, who might the "AI" turn into an adversary? Who might you overwhelm with an asymmetric amount of output, or, if you're receiving information and not sending it, who are you taking that information from without consulting?

Figure out the answers to these questions and conduct yourself accordingly; the answer might be "yourself".

Acknowledgments

Thank you to my patrons who are supporting my writing on this blog. If you like what you've read here and you'd like to read more of it, or you'd like to support my various open-source endeavors, you can support my work as a sponsor!

23 Jun 2026 8:06pm GMT

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

09 Jun 2026 12:00am GMT