Codex CLI sessions are easy to manage when only one task is active. The workflow becomes less predictable when several sessions operate in different repositories or terminal tabs. A task may be blocked on an approval while another is still running and a third is ready for review.
In the first half of 2026, we discovered activity by the East Asian threat group FamousSparrow. Its attacks targeted several countries in South Asia and Europe. In these attacks, the threat actor used its own malware: a heavily reworked variant of the modular SparrowDoor backdoor and a new backdoor that we named SquawkDoor.
FamousSparrow, also known as Salt Typhoon and Earth Estries, is an East Asian threat group that has been active since 2019. The group is known for using its proprietary SparrowDoor backdoor and initially focused on attacks against hotels worldwide, as well as government and international organizations. Later, FamousSparrow began actively targeting telecommunications companies and internet service providers, apparently seeking long-term access to lawful communications intercept systems.
In these attacks, the threat actor used both malicious LNK files and a website compromise vector involving malicious JavaScript. The injected script displayed a fake error message when a user visited the page and prompted them to download a new certificate. In reality, the download was a malicious executable that led to backdoor infection. The attacks were tailored to specific countries: the JavaScript samples and payloads contained text customized for the target country.
For several weeks, I logged every moment when understanding our system required asking another person instead of reading code, documentation, dashboards, or configuration. What started as a small experiment turned into a surprisingly useful map of hidden knowledge dependencies. The biggest risk was not missing documentation. It was that some parts of the system effectively existed inside one engineer's head.
Due to recent rapid progress in the field of large language models (LLMs), many have speculated about artificial general intelligence (AGI). This paper addresses the keystone question: Are LLMs capable of transitioning to AGI? The paper presents a framework for estimating the logical limits of cognitive systems, which highlights the conflicting design requirement, namely, being able to proficiently execute both strict and loose logic. LLMs are gravitating towards loose logic and that inhibits their ability to grasp the essence of complex topics.
I write about the point where software abstractions meet irreversible authority, with an emphasis on threat models, negative tests, and systems that fail closed.
DeepSeek Harness is often described as an open-source coding agent. That description is correct, but incomplete. The more interesting part is its architecture. DeepSeek Harness is a configurable runtime for constructing agents from model adapters, tools, session services, execution backends, permission policies, interfaces, and agent loops.
From 18 to 21 November 2026, Nepal will host PGConf.Nepal 2026, the country’s fourth PostgreSQL conference. The previous events took place in 2018, 2023, and 2025. This year, the conference is expected to bring together a wider mix of participants, organisations, and countries.
The journey from a single A100 in the cloud to an H200 cluster is not just a hardware upgrade — it’s a story of how an ML team stopped chasing “the one perfect model” and started building an ecosystem. When there are millions of lines of PostgreSQL C code under the hood and tasks range from hint-set generation to Graph-RAG, the model stops being a black box and becomes just another replaceable component. We explain how we rebuilt our stack around vLLM and MCP, why context management matters more than model weights, and how we made a 0.6B-parameter model perform on par with the giants using GRPO.
Hello, Habr!
For many IT professionals, the ultimate personal finance setup involves a massive Google Sheet or a complex Notion database. I completely understand this approach: when you spend your entire day sitting in front of a monitor, entering data into a cell takes two seconds.But 7 years ago, my reality was entirely different. I was an entrepreneur, and my workday meant constant movement. I was driving, visiting warehouses, meeting partners, or checking production floors. I was 100% mobile, and the only tool I always had on hand was my iPhone.
In that fast-paced rhythm, traditional finance trackers and spreadsheets simply fall apart. Here are typical scenarios from my life back then:
I wanted to see what actually changes when the same small data-processing program travels through four generations of programming languages. So I built it in BASIC, C, Pascal and Python, kept the algorithm as similar as possible, and compared not only execution speed but also memory use, binary size, debugging time and the amount of code I had to keep in my head. C was fast. Python was short. Those parts were predictable. BASIC and Pascal were where the experiment became interesting.
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 market for proxy providers has grown exponentially in just the last couple of years.
To be fair, the ”proxy boom” hit right during the golden era of the 2020s, and overall, the growth trend continues to rise. In fact, I believe in the next few years, we will witness a total revolution in automation and related services. Reimagining, repackaging, and rolling out new features — I’m certain we have yet to peak in abilities.
However, the larger the market grows, the breakdown of components becomes much more interesting — 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 incredibly inefficient and inaccurate. Since I have hands-on experience with many of these players, I'll share my firsthand knowledge, in hopes of it being useful to others.
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.
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.
An uncensored ai chatbot sounds like a product category, but from an engineering perspective it describes an implementation detail badly. When an LLM refuses a request, the refusal may originate in the model weights, a system prompt, an input classifier, an output classifier, or an application policy enforced outside inference entirely.
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.