LLMs hallucinate — everyone has seen what it looks like. The model reports, confidently and coherently, with the right intonation and terminology, something that isn't there. Engineers treat this as a bug: one being fixed, one about to be fixed.
It won't be. This is not a technical fault but an inherent property of language, which the machine has made visible.
After watching a veteran programmer debug a nasty issue without searching for a ready-made answer, I decided to copy his workflow for seven days. Google stayed closed, Stack Overflow was off limits, AI coding tools were disabled. Documentation, source code, logs, debuggers and man pages were still allowed.
The week was slower than expected. It was also much more useful than expected.
Two bugs in particular changed the way I think about debugging: a TCP problem that looked like broken JSON and an asyncio problem that looked like random network freezes.
What do 1C queries, IN (VALUES ...) constructs, and the innocent expression x + 0 have in common? They can all turn a millisecond query into a multi-minute wait because PostgreSQL's standard planner "trips" over them. We break down how the pgpro_planner extension rewrites tricky parts of the query tree into a friendly form before the optimizer picks a bad plan — and why some of these fixes have already made it into vanilla PostgreSQL 18.
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.
My name is Anton Omelianenko and I’m head of software development. A manager runs a team so that it delivers results for the business. To judge how well people are handling their work, a manager needs data and a system for assessing it. In software development this is harder than it looks.
This article covers three questions: why classic metrics fail when assessing developers, how to measure performance properly and what to do when an employee may not be working only for you.
A personal technical retrospective about moving away from framework-first development, reducing client-side JavaScript, using server-rendered HTML, and treating browser APIs as architectural tools rather than outdated limitations.
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.
On June 28, 2025, the European Union’s transition period for the European Accessibility Act ended. For a broad range of commercial services—online stores, banks, transport, and telecom—web accessibility stopped being a matter of goodwill.
Technically, the requirement comes down to EN 301 549 and, for the web, WCAG 2.1 Level AA. You cannot learn WCAG by reading it: half the criteria sound perfectly clear while leaving it completely unclear what exactly should be written in the markup.
Some of our projects fall under the new requirements, and it is not only front-end developers who need to relearn their habits. Designers set contrast and focus order, analysts write error messages, and testers need to know what to check manually.
That is how a project of 20 exercises emerged. In each one, the page looks fine at first glance. It is broken only from an accessibility perspective: headings skip levels, a div with a click handler acts as a button, a label sits next to an input but is not formally associated with it. You edit the markup and immediately see the result as the page rebuilds on the fly. Everything runs directly in the browser, and both your code and progress stay in localStorage: a11y-exercises.github.io
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.
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.