Python *

AI-generated code often looks cleaner than code written by a tired developer at 2 a.m. It has sensible names, neat layers, comments, tests and even error handling. The problem starts when the code meets something the prompt forgot to mention: two requests at once, a repeated webhook, a cancelled task or a database failure halfway through an operation.

This article is about bugs that stay invisible during a normal code review. I took several ordinary backend tasks, generated working solutions and then tried to break them with timing, retries and bad input. The code compiled. The tests were green. Some of it was still unsafe.

A normal code review comment usually sounds harmless.

Rename this variable. Move this method. Add a test. Remove the duplicate condition. But sometimes an experienced developer leaves a much shorter comment: No.

Not maybe. Not could we simplify this. Just a clear rejection of the entire approach.

For a junior developer, this can feel strange. The code compiles, tests pass, the implementation is readable, and the ticket requirements seem complete. Why throw it away?

I started saving such cases after one of my pull requests was rejected for the third time in a week. The goal was not to prove that the reviewer was wrong. I simply wanted to understand what experienced engineers noticed before everyone else.

Over several months, I collected review discussions from backend services, internal tools, queue consumers, APIs, and data-processing jobs. I removed comments about formatting and naming. Only full design-level rejections remained.

The result was a small catalogue of professional paranoia.

And honestly, most of it was useful.

Deleting code sounds easy until the code belongs to a running product.

A function may have no direct callers but still be loaded through a plugin registry. A serializer may look duplicated but quietly preserve an old field name used by one customer. A command may not appear in analytics because it runs from cron at 3:10 a.m. on the first Sunday of each month. Python makes this even more fun because imports, decorators, entry points, reflection, monkey patches, and strings can all become hidden edges in the dependency graph.

The project in this story was a multi-tenant reporting backend written in Python. It accepted events, stored normalized records, generated reports, exported CSV and JSON files, and delivered them through HTTP, email, and object storage. Nothing huge. Around 140 API endpoints, 46 background tasks, PostgreSQL, Redis, and a queue.

The repository contained 62,914 lines of Python excluding tests and migrations.

That number was not the actual problem. The problem was that a small change in report filtering could require edits in the API schema, a service class, a repository, a filter translator, a query builder, an export adapter, and several nearly identical tests. The system had layers, but the layers did not reduce complexity. They distributed it.

The first plan was a rewrite. Fortunately, that plan died before production did.

Instead, the question became much simpler: How much code can disappear while externally observable behavior remains unchanged?

That wording changed the whole project.

Our office has roughly one hundred employees, but for a long time we had no proper help desk process. Requests arrived through email, corporate chat, phone calls, and random conversations in the hallway. It always felt as if most of the day was spent dealing with servers, networks, backups, and serious incidents.

To check whether that impression was accurate, I logged every support request for one month. I measured active work time, recorded the cause of recurring problems, tracked waiting periods, and counted how often a new request interrupted something already in progress.

Over 22 working days, I recorded 496 contacts. After merging duplicate reports related to the same issue, those contacts became 421 separate support episodes.

The most surprising result was not the total number of requests. It was the damage caused by short five‑minute tasks constantly breaking longer technical work into small, nearly useless fragments.

This article explains how I collected the data, why average resolution time is often misleading, how I automated Windows workstation diagnostics with PowerShell, and how I processed the resulting event log using Python and PostgreSQL.

Wearable devices present a paradox: the band measures your heart rate, sleep, and activity, but the manufacturer doesn't provide a ready-made open API to integrate this data into third-party systems (like a home monitoring setup or a local database). The official Xiaomi Mi Fitness app shows beautiful graphs, but the data remains 'locked' within the mobile ecosystem.

The initial task was purely practical: to set up automatic collection of health data into a local SQLite database and display reports in a family Telegram bot. Since the band syncs with the app, which in turn syncs with the Xiaomi cloud, the data is guaranteed to be transmitted over the network. I needed to understand the format in which it's transmitted and how to retrieve it.

This article is a technical breakdown of the journey from analyzing network traffic and setting up trust for a custom CA to reverse-engineering Xiaomi's RC4 protocol, decrypting AES/CBC objects from FDS storage, and parsing the proprietary binary sleep format.

The modern world is saturated with all kinds of information, and in our difficult times, it's important to be able to not only find it but also to save it. Many have probably noticed that on YouTube, besides the junk, cats, and other useless things (which we sometimes don't mind watching), there is a lot of useful material on a wide variety of topics. And sometimes it would be nice to save this material for the future, so as not to depend on the changing moods in the world.

In this article, I want to explain how you can download videos, audio (Part 1 of the article), playlists, and entire channels from YouTube (Part 2 of the article) without using a VPN and in pure Python. A quick disclaimer: we won't need a VPN, but we will create our own tool that will solve the "problem with outdated and worn-out equipment Google Global Cache" (you know what I mean). I think this tool will be especially relevant today, when for many Russians, YouTube barely works or doesn't work at all.

Hello, Habr! My name is Nikita Pastukhov—author of FastStream, Principal Engineer, and maintainer of AG2 (a framework for developing agents). I’ve been in development for 8 years, and for the last year, I’ve been up to my ears in agents.

And I want to prove to you that writing your own agent is no more difficult than writing a CRUD

Why does this even need proving? Because there’s a noticeable gap between what’s happening with AI globally and what’s happening in the average Russian company. Globally—every company has an OpenAI subscription, there are a billion startups with AI products, and agents are deeply integrated into the back office. In Russia—it’s “dangerous, we host our own models,” “it’s unclear,” and support chatbots. Globally, engineers already know how to develop agents. In Russia—it’s “what even is that?”

So let’s break down how agents work using the example of OpenClaw—the most hyped “personal AI agent” right now. It lives in your messenger, sorts your email, manages your social media, writes code, and deploys services. Its popularity is a testament to how little people are currently using agents in their daily lives. For those in the know, OpenClaw hasn’t brought anything new to the table.

For over 10 years, C++ has had constexpr, which allows the programmer to cleverly offload some computations to the compiler. At the time, this blew my mind, because the compiler can calculate some rather complex things before the program is even run!

At some point, I thought: if the compiler can calculate everything for you, then why do you need a runtime at all? What are you going to do there—print the answer or something? That’s just silly. That’s unsportsmanlike.

This is where my challenge was born:

“No hands” or “don’t even think about running the exe file”

Every day, every single day, devices in fire suppression systems need to be checked! When these are enormous warehouses spread across vast territories, a security guard has to constantly walk around and inspect all of them — just for this one task. The pressure gauge has become a symbol of punishment in fire safety authorities.

Millions of analog sensors are also used in gas and water distribution systems, as well as in many other industries.

We are all fascinated by the ability of AI to describe what is happening in front of a video camera, but so far we have not seen anyone answer the question — why? Is there at least one truly practical use case?

At SpecLab, however, we came up with our own application...

In the previous article I described my “anime factory” in detail — a pipeline that automatically turns episodes into finished Shorts. But inside that system there is one especially important module that deserves a separate deep dive: a virtual camera for automatic reframing.

In this article, I will break down not just an “auto-crop function,” but a full virtual camera algorithm for vertical video. This is exactly the kind of task that looks simple at first glance: you have a horizontal video, you need to turn it into 9:16, keep a person in frame, and avoid making the result look like a jittery autofocus camera from the early 2010s.

But as soon as you try to build it not for a demo, but for a real pipeline, engineering problems immediately show up:

Hi, Habr!

Over the past few months, I have been building a system that I internally call an “anime factory”: it takes a source episode as input and produces a ready-to-publish YouTube Short with dynamic reframing, subtitles, post-processing, and metadata.

What makes it interesting is not just the fact that editing can be automated, but that a significant part of this work can be decomposed into engineering stages: transcription, audio and scene analysis, strong-moment discovery, “virtual camera” control, and a feedback loop based on performance metrics.

In this article, I will show how this pipeline is structured, why I chose a modular architecture instead of an end-to-end black box, where the system broke, and which decisions eventually made it actually usable.

Our test framework broke as services grew. We redesigned it with clear layers to scale tests, reduce coupling, and support SDKs and AI.

Hello, fellow developers!

Anyone who designs multilayer printed circuit boards in KiCad has faced the need, during routing, to leave large areas free of copper polygons (whether connected to nets or not) for schematic or other reasons. On outer layers, this isn't a big problem. On inner layers, it's a bit different. While it might be fine from a topology perspective, it's not ideal from a manufacturing point of view.

Today, we want to share a plugin we developed to solve this problem. It's a tool for automatically filling free areas on a PCB with non-current-carrying copper elements, either square or round, of a configurable size.

Why is this needed?

At first glance, an empty area on a board is just bare laminate without copper. But for the manufacturer and the end-user of the device, this has two important consequences.

The Chinese neural network DeepSeek has recently gained popularity. Today, we'll figure out how to work with its API, how to pay for it from Russia, and whether there are any difficulties.

Ollama has become the standard for running Large Language Models (LLMs) locally. In this tutorial, I want to show you the most important things you should know about Ollama.

In this article, I will show you how to build your first AI agent from scratch using Google’s ADK (Agent Development Kit). This is an open-source framework that makes it easier to create agents, test them, add tools, and even build multi-agent systems.

My name is Anatoly Bobunov, and I work as a Software Development Engineer in Test - or SDET for short - at EXANTE. When I joined one of our projects, I discovered that several of our test suites took more than an hour to run - painfully slow, to the point where running them for every merge request was simply unrealistic. We wanted fast feedback on each commit, but at that speed, it just wasn’t going to happen.

Eventually, through a series of small but precise improvements, I managed to speed things up to 8.5× faster, without rewriting the tests from scratch. In this article, I’ll walk through the bottlenecks we found and how we fixed them.