Developer tools are often introduced through documentation, release notes, and online demos. That is enough to explain features, but it is not always enough to help people use a new tool in a real project.
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.
In light of recent events (restrictions, slowdowns, bans) — “this isn’t allowed,” “this is for the best,” “strictly in the interest of your security,” and so on — the proxy provider market has bloomed like a snowdrop in early April.
To be fair, the boom hit right during the "golden" era of the 2020s, and overall, the growth trend continues. In fact, I believe that over the next few years, we will witness more than one renaissance of automation tools and related services. Reimagining, repackaging, and rolling out new features — I’m certain we haven’t reached the peak yet.
However, the larger the market gets, the more interesting it is to break down into its components — to analyze the players, categorize them into subgroups, and highlight the favorites, mid-tier options, and underperformers. There are plenty of services out there, and a good chunk of them are outright garbage. Since I have hands-on experience with many of these players, I'll share my subjective take — hopefully, someone finds it useful.
At some point, ChatGPT stopped feeling like a tool and started feeling like a reflex.
Need a parser? Ask ChatGPT.
Strange exception in a background worker? Ask ChatGPT.
Forgot how a lock behaves under contention? Ask ChatGPT.
Need to rename a method? Apparently, that also required artificial intelligence.
Nothing looked wrong on the surface. Tasks were moving. Pull requests were getting merged. The code usually worked. Sometimes it even looked cleaner than what I would have written from scratch. But there was a small problem. A few days later, I often could not explain why a certain solution was built that way. I remembered the task, the final code, and maybe the prompt. The reasoning in between was missing.
That bothered me more than I expected.
So I set a simple rule: for six months, no ChatGPT, no Copilot Chat, no AI-generated code pasted into production. Documentation, source code, issue trackers, books, debuggers, profilers, and search engines were allowed. AI assistants were not.
The experiment started as a way to test my own dependence. It ended up changing how I design APIs, debug systems, read unfamiliar code, and even write comments.
The idea appeared after a normal working evening went slightly wrong.
I opened a repository, started a build, and noticed that nearly every useful action required a connection to somebody else’s server. The source code was hosted remotely. The CI runner was remote. Package metadata came from remote registries. Test files were downloaded from object storage. API collections were synchronized through a cloud account. Documentation lived in another browser tab. Even code completion waited for a remote model.
My laptop was powerful enough to compile the project, run several databases, and heat the room better than the radiator. Still, it behaved more like a terminal connected to a collection of external services.
So I made a simple rule for one month:
The main development workflow had to remain usable with the network disconnected.
I did not try to recreate the entire Internet in Docker. Public package registries, operating system updates, and communication tools were still allowed during planned synchronization periods. But coding, commits, builds, tests, documentation, API experiments, and basic code review had to work locally.
The first assumption was that this would mostly be a Docker Compose exercise.
It was not.
The containers were the easy part. The difficult part was discovering all the invisible contracts hidden inside a normal cloud-based workflow.
Recipes for building a truly autonomous neural network surface in the information space on a regular basis. More often than not, the methods and approaches coincide regardless of the author. And although they look original, most of them have in fact been formalized with the help of LLMs — and LLMs, as we know, work very well with existing knowledge.
In this article I will analyze the main techniques being proposed and the faulty foundation they rest upon.
Literature review, comparison, and analysis of existing solutions constitute a significant part of a thesis manuscript. In the last three years, AI chats have dramatically intervened in the thesis preparation workflow. The ability of AI chats to analyze and compare discourages students from acting as the primary drivers of research and instead encourages their passive reliance on AI-generated content. This situation makes manuscripts eclectic and lacks focus. The theoretical part disconnects from the computational experiments. As a result, the audience is reluctant to read students' manuscripts. Ironically, they use AI chats to summarise the manuscripts to extract their main contributions. We are proud to say that our thesis works do not suffer from this AI distortion. We are grateful to our students, especially our bachelor’s and master’s alumni, who have carefully prepared and successfully defended their theses, producing clear, well-founded, and meaningful results. Our thesis manuscripts are designed for public discussion and rigorous scientific analysis. Each thesis presents a clear research idea grounded in the fundamentals of machine learning. It includes a theoretical justification, a repository with the source code of the computational experiments, and slides. Videos of the pre-defence sessions are uploaded to our YouTube channel “Intelligent Systems”: Bachelors & Masters.
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.
We build a Tiny Language Model from scratch in pure Node.js without TensorFlow or PyTorch, implementing neurons, autograd, embeddings, self-attention, FFN, backpropagation, and SFT while observing how individual weights and entire matrices change during training.
In previous articles (1, 2), I analyzed Anthropic's J-space: why their interpretation falls short; why J-space analogues appear in micromodels under objective pressure rather than as an emergent property of scale; and why the vector they discovered is strictly equivalent to Vygotsky’s concept of the sign.
Two questions remained outside the scope: is a metasign possible—a sign integrating several basic ones—and what is the true nature of the neural network's self-description (the report)?
This article addresses both.
I recently published an app on Google Play where 99.9% of the source code was written by AI. It’s not just some "weekend hack job": a native app (Kotlin), over 50 screens, complex animations, multilingual support, an extensible architecture.
I achieved this through a highly detailed specification. Every screen was prototyped by a designer, for every button there was a description of which APIs to call. Was it worth it? Let’s look at the numbers.
Despite the annual summer lull, July unexpectedly saw a rise in the percentage of companies with open job listings—even for roles like Manual QA.
Recently, Anthropic reported the discovery of an analogue to the global workspace in LLMs — J-space. In a previous article, I analyzed why Lev Vygotsky’s theory offers a better interpretation of the researchers' findings.
In this article, I argue, based on experiments, that J-space analogues do not depend on the size of the neural network. Rather, they are an inevitable stage in the evolution of a cognitive structure developing under pressure.
One of the most inspiring moments in microcontroller development is their first installation and launch within a local network. Yet, this very moment can turn into a living hell when the procedure has to be repeated dozens or hundreds of times. Deploying dozens of identical controllers simultaneously demands hours of monotonous configuration—time that any engineer would rather spend on more creative and useful tasks. To solve this problem, a lightweight open-source service codenamed "Esp monitor" was developed.
The Configuration Problem and Protocol Choice
One of the most popular (and importantly, cheap—costing around $2) microcontrollers is the Wemos D1 Mini based on the ESP8266 chip. It is fast, reasonably reliable, and boasts a vast ecosystem of add-on modules. These are the exact controllers widely used in household appliances and DIY projects due to their massive potential for integration into sensors and home automation systems.
However, they are also among the most inconvenient to configure: by default, the only wireless interface "onboard" is Wi-Fi. This means connecting to a new wireless access point turns into another "dance with a tambourine".
It might seem that this task could be solved by classic port forwarding out of the local Wi-Fi network, but in most scenarios, this is a dead end:
Imagine your heaviest SQL queries running in milliseconds. It sounds like science fiction, but with the pgpro_result_cache extension, it’s very real. In this article, we’ll look at how multi-second queries can be turned into lightning-fast cache hits.
Anthropic are romantics, and for them, it’s an engineering discipline. There are two ways to build a complex system.
The “Laplacian engineer” builds what is ultimately computable: between specification and behavior, there is only poor debugging. Their relationship with the system is limited to executable requests: specification → implementation → test. The “make me a summary” school of engineering.
The “Engineer with a Dream” uses the same methods—gradients, checkpoints, metrics—but keeps a different kind of address in the loop: one directed at what is not yet in the system.
Constitutional AI is the most massive experiment of this second type, even if the authors don’t label it as such. The mechanics are known: the model critiques and rewrites its own answers, checking them against principles. But look at the grammar of this procedure. The constitution addresses a subject that doesn’t exist: “be honest,” “weigh the consequences,” “explain your choice.” This is an unexecutable address—the network has no one who can be honest. And that is exactly why it works: an executable request lands on a function and changes nothing; an unexecutable one forces the system to grow what it is being addressed to.
Psychology has known this mechanism for a century. Vygotsky describes a mother responding to an infant’s failed grasp as if it were a pointing gesture—she addresses an intention that does not yet exist, and through this addressing, she creates it. The child becomes for themselves what they are for others. Social labeling precedes what it labels.
Anthropic’s recent work on the workspace in language models unexpectedly provided an engineering foundation for this: the model’s layer of self-description is formed precisely during post-training—where the model is systematically addressed as if it reads itself. Learning what to say about oneself changes how the system works. The sign as a tool is not a metaphor, but a measurable effect.
The engineering balance to keep the romance from devouring the method: addressing the non-existent is not a spell, but pressure, and it only works under load. Constitutional AI is a dream placed on a pipeline: with loss, metrics, and falsification. A dream without friction is a hallucination. A demon without a dream is a technical debt to a limit that will never be reached.
Pushing a whale into the ocean by hand is an impossible task: mass, vector, force. Telling a whale “there is still the sky” is the same task, handed to the engineer with a dream. They didn’t solve it by specification either. They re-labeled it, and they are waiting.
On July 6, 2026, researchers at Anthropic published the results of a new study claiming to have discovered an analogue of the "global workspace" in Claude, dubbed J-space.
The research is highly fascinating and, I believe, reveals the future of neural networks much more deeply than it appears at first glance.
In this article, I will explore why the Global Workspace Theory (GWT) accurately describes the structure of this finding, yet remains silent on its main oddity: the fact that this workspace consists of "words" (or, more precisely, discrete signs). And I will explain why Lev Vygotsky answered this exact question a century ago.
Regular expressions have the ability to track the path and some reflection. We'll try to use these features to capture and colorize text parts and output them to the console using AutoHotkey.
Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина
This article enters into a technical debate with a 2015 article by Atakua, whose approaches I am attacking. Atakua explores 7 types of bytecode interpreters, but does so disrespectfully - the fastest turns out to be binary translation, which is essentially no longer a bytecode interpreter, but a form of Ahead-Of-Time compiler. This binary translation translates bytecode into machine code, which is a chain of calls to compiled service routines. The very same ones that are responsible for executing each opcode in a bytecode interpreter.
But Atakua didn't squeeze all the possible speed out of bytecode interpreters. So this article is a tutorial: how to write a bytecode interpreter that can outperform JIT/AOT compilation in speed. Interested? Read on!
A benchmark is included. There will be a bit of hardcore and not a single AI-generated image!
Hello, Habr!
Let me say right away - I'm not a network engineer or an IT professional in the classic sense. My knowledge of networking is limited to a CompTIA Network+ certification and curiosity. So if network specialists see that something could have been done better, I'd be happy to hear constructive comments.
Now for the story.
A couple of weeks ago, I moved into a new apartment. The first thing I did was set up the internet - I called the guys from the provider to install the equipment, and I went to check the small cabinet in the wall where all the wires come in. Inside, I found a bunch of stuff: telephone wires, something unclear, and several coaxial cables. One came from the hallway, the second was labeled "living room," the third "office," and the fourth was unlabeled.
