Из-за внедрения ИИ сотрудники начали чаще уставать и быть менее продуктивными

Генеральный директор стартапа в сфере программного обеспечения Convictional Роджер Киркнесс рассказал, что после внедрения инструментов искусственного интеллекта для сортировки электронной почты, ведения протоколов совещаний и составления отчётов о расходах наблюдался прирост производительности на 20%. При этом в стартапе обнаружили, что сотрудники столкнулись с выгоранием от высокого темпа высокоуровневой когнитивной работы.

Киркнесс заметил, что после того, как ИИ снял с его команды рутинную работу, сотрудники посвятили себя задачам, связанным с интенсивным мышлением, но к пятнице все они оказывались истощены и были непродуктивными. Компания перешла на четырёхдневную рабочую неделю, но объём работы остался прежним.

Основная проблема, по словам экономиста и социолога из Бостонского колледжа Джульет Шор, заключается в том, что предприятия, как правило, просто перераспределяют время, сэкономленное ИИ. От работников, которые раньше умственно снижали концентрацию внимания при таких задачах, как ввод данных, теперь ожидается поддержание высокой концентрации на протяжении более длительных периодов. «Если вы просто заставляете людей работать в высоком темпе без перерывов, вы рискуете подавить творчество», — говорит Шор.

То есть условно бесполезная или монотонная работа, которую призван заменить ИИ, в реальности позволяла в какой-то мере челевоку "передохнуть" (работать в меньшем темпе, с меньшими усилиями), а без этой "бесполезной работы" усилилось выгорание и уменьшился творческий потенциал работников.

https://www.msn.com/en-us/technology/artificial-intelligence/the-downside-to-using-ai-for-all-those-boring-tasks-at-work/ar-AA1TMuha

Линус Торвальдс признался, что не умеет писать на Python. И использовал ИИ

Линус Торвальдс выложил на GitHub новый хобби-проект AudioNoise — набор цифровых эффектов для гитары. В README Торвальдс честно написал, что Python-визуализатор сделан с помощью вайб-кодинга через Google Antigravity. Причина проста: в Python он разбирается даже хуже, чем в аналоговых фильтрах. Основной код проекта написан на C вручную, ИИ использовался только для визуализации аудиосэмплов.

Торвальдс описал эволюцию своего подхода: раньше он гуглил примеры и копировал код в стиле "обезьянка видит — обезьянка делает" ("google and do the monkey-see-monkey-do"), а теперь "убрал посредника — себя". AudioNoise продолжает его увлечение самодельными гитарными педалями — в анонсе Linux 6.13 он назвал это хобби "LEGO для взрослых с паяльником". Новый проект эмулирует аналоговые эффекты (фейзер, фленжер, эхо) через цифровые IIR-фильтры, работающие без задержек по принципу "один сэмпл на входе — один на выходе".

Сам проект Торвальдса - https://github.com/torvalds/AudioNoise

Свежо предание...
Но, думается мне, и к концу 2026 года эти прогнозы не сбудутся.

Шпаргалка по разрядам чисел, максимальным и минимальным значениям

Как изменятся зарплаты айтишников в 2026 году

«Золотой век» начинающих айтишников (джунов) закончился, а рынок IT переживает перезагрузку после бурного роста, сообщили в SuperJob.
По данным рекрутингового сервиса, вакансий стало меньше (-13%), а конкуренция среди начинающих специалистов резко выросла (+11% резюме). Предложение зарплаты в целом по IT-сфере за 2025 год выросло на 8,8%.

Среди самых высокооплачиваемых направлений для IТ-специалистов остается область разработки ИИ. В это направление входят такие специальности, как написание LLM на Fine tuning и инференс-моделях, RAG, AI-продакты.
«Зарплатная вилка здесь составляет от 500 тыс. до 1 млн руб., так как спрос рынка на этих специалистов только растет и эта тенденция продолжится».

Второе место занимают направления AppSec/DevSecOps. Мидл-специалисты здесь могут получать от 400 тыс. до 700 тыс. руб.

Также востребованы сейчас и Go-разработчики (специалисты по ПО на языке программирования Go), зарплаты которых начинаются от 400 тыс. руб.

В топ попадают менеджеры по развитию бизнеса и специалисты по продажам в области IT. В 2026 году ситуация останется похожей.
Максимальные доходы традиционно сохраняются у solution-архитекторов и техлидов, где зарплаты senior-уровня достигают самых высоких значений благодаря ответственности за архитектурные решения и стратегию развития продуктов.
Чуть ниже, но также в верхнем сегменте находятся специалисты по AI и ML, так как компании продолжают активно внедрять инструменты анализа данных и автоматизации.

Следующую позицию занимают эксперты по DevOps и SRE, обеспечивающие стабильность и масштабирование систем.
В группе высоких доходов остаются специалисты по кибербезопасности, на которых растет нагрузка из-за увеличения числа киберугроз.

Пятерку замыкают опытные full-stack-разработчики, особенно если они работают со сложными и востребованными стеками, совмещая несколько направлений разработки.

В 2026 году в зарплатах айтишников не стоит ожидать резкого роста. Повышение сохранится точечно, прежде всего для специалистов по кибербезу, ИИ и инфраструктуре, с наибольшим спросом на опытных специалистов и более сдержанными ожиданиями по джунам.

На рынке труда в IТ в 2025 году значительно усилилась конкуренция за вакансии на фоне сокращения общего числа открытых позиций. Рост зарплат по отдельным специальностям и уровням в ряде случаев не покрывает уровень инфляции.
Наиболее сложная ситуация сохраняется для специалистов начального уровня: компании все реже инвестируют в массовый наем джунов, отдавая приоритет более эффективным сотрудникам.
В то же время конкуренция работодателей за специалистов middle+ остается высокой, и именно в этом сегменте возможна точечная корректировка зарплат в 2026 году.

В целом в IT-сфере из-за эффекта высокой базы темпы прироста доходов будут снижаться, в прогнозе SuperJob на 2026 год указан средний рост зарплат на 8–10%.
Однако у стратегически важных IT-специалистов (архитекторов, DevOps, разработчиков senior-уровня, ML-инженеров) заработные платы будут расти быстрее — на 12–15%.
Разрыв в зарплатах между junior- (начинающими) и senior- (старшими) специалистами продолжит расти, констатировали в рекрутинговом сервисе.

https://www.rbc.ru/life/news/695241d59a79474610e80e31

Краткая шпаргалка по архитектурным паттернам и стилям
(продолжение в следующем посте)

Краткая шпаргалка по архитектурным паттернам и стилям
(продолжение предыдущего поста)

1. Архитектурные паттерны (Architectural Patterns) — это проверенные решения для типичных задач проектирования архитектуры ПО. На схеме представлены ключевые паттерны:
* MVP (Model-View-Presenter) — разделяет логику представления, данные и управление взаимодействием;
* MVC (Model-View-Controller) — классическая схема разделения на модель (данные), представление (UI) и контроллер (логика взаимодействия);
* MVVM (Model-View-ViewModel) — улучшает MVC, добавляя слой ViewModel для привязки данных;
* DDD (Domain-Driven Design) — фокусируется на модели предметной области, отделяя бизнес-логику от инфраструктуры.

2. Архитектурные стили (Architecture Styles) — определяют общую структуру и взаимодействие компонентов системы. Примеры на схеме:
* Monolith — монолитная архитектура, где всё приложение — единый блок;
* Layered — слоистая архитектура (например, UI, бизнес-логика, данные);
* Event-Driven — управление через события (асинхронные взаимодействия);
* Microservices — система из независимых сервисов, взаимодействующих через API;
* Space-Based — архитектура, ориентированная на распределённое хранение данных;
* Master-Slave — главный (Master) управляет подчинёнными (Slave) узлами;
* SOA (Service-Oriented Architecture) — сервисы взаимодействуют по стандартизированным интерфейсам;
* Mikrokernel — ядро с минимальным функционалом и подключаемыми модулями;
* Serverless — выполнение кода без управления серверами (например, через облачные функции);
* Hexagonal — разделение на ядро (бизнес-логика) и адаптеры (интеграция с внешними системами);
* Clean — чёткое разделение на слои: домен, приложение, инфраструктура;
* REST — архитектурный стиль для веб-сервисов с принципами stateless, cacheable и др.

3. Паттерны проектирования (Design Patterns) — шаблоны для решения конкретных задач на уровне классов и объектов. Разделены на три группы:
* Creational (порождающие) — управляют созданием объектов:
* Factory Method, Abstract Factory, Builder, Prototype, Singleton.
* Structural (структурные) — организуют структуру классов:
* Adapter, Bridge, Decorator, Composite, Facade, Flyweight, Proxy.
* Behavioral (поведенческие) — определяют взаимодействие и алгоритмы:
* Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

Итог:
* Архитектурные стили задают «скелет» системы (как компоненты взаимодействуют).
* Архитектурные паттерны — готовые схемы для конкретных задач (например, разделение логики в MVC).
* Паттерны проектирования — микрорешения для кода (как создавать, структурировать и связывать объекты).

Все эти элементы помогают проектировать ПО, балансируя между гибкостью, масштабируемостью и поддерживаемостью.

В сети представлен скрипт PowerShell для удаления функций ИИ из Windows.

Скрипт доступен в репозитории на gtihub:
https://github.com/zoicware/RemoveWindowsAI?tab=readme-ov-file

Как сказано в преамбуле проекта, цель скрипта — удалить ВСЕ ИИ функции для улучшения пользовательского опыта, конфиденциальности и безопасности, так как текущая сборка Windows 11 25H2 и будущие сборки будут включать в себя всё больше функций и компонентов ИИ.

Среди функций скрипта, в частности:

Отключение Copilot
Отключение Recall
Отключение Input Insights и сбора данных о наборе текста
Copilot в Edge
Image Creator в Paint
Удаление службы AI Fabric
Отключение действий ИИ
Отключение ИИ в Paint
Отключение голосового доступа
Отключение голосовых эффектов ИИ
Отключение ИИ в поиске по настройкам

ИТ-шники из Индии уже в России. Но есть нюансы...

"«В основном я работал в компаниях вроде Microsoft и использовал новые инструменты — ИИ, чат-боты, чат GPT и тому подобные, по сути я разработчик», — улыбаясь рассказывает журналистам смуглый мужчина в шапке и рабочей форме. С корреспондентами он говорит на английском.

Индийского IT-шника отвлекли от подметания улицы в Санкт-Петербурге. Вместе с другими 16 трудовыми мигрантами он приехал из Индии в северную столицу еще осенью прошлого года. Их устроило к себе ​​АО «Коломяжское», которое занимается уборкой и очисткой территории...."

https://www.gazeta.ru/social/2026/01/14/22334203.shtml

5 базовых концепций для высокой доступности приложения
(продолжение в следующем посте)

5 базовых концепций для высокой доступности приложения
(продолжение предыдущего поста)

Постоянная доступность приложения, особенно высоконагруженного, является одной из распространенных проблем при разработке и поддержке приложения. Рассмотрим 5 базовых концепций для высокой доступности на основе схемы:

1. Распределение нагрузки (Load Balancing)
- Суть: распределение входящих задач или запросов между несколькими экземплярами системы.
- Как реализовано на схеме: центральный элемент — Load Balancer — принимает запросы от клиентов (например, с ноутбуков или мобильных устройств) и направляет их на доступные экземпляры сервисов (Payments API, Orders API).
- Цель: предотвратить перегрузку отдельных компонентов, равномерно распределить нагрузку, повысить общую производительность и доступность системы.
- Дополнительно: Load Balancer выполняет проверки работоспособности (health checks) и перенаправляет трафик, если один из экземпляров выходит из строя.

2. Микросервисная архитектура (независимые сервисы)
- Суть: разбиение системы на небольшие независимые сервисы, которые работают автономно.
- Как реализовано на схеме: показаны отдельные сервисы — Payments API (с собственной базой данных — Payments Database) и Orders API.
- Цель: изоляция сбоев — если один сервис выходит из строя, это не влияет на работу других. Это повышает устойчивость системы (resilience).
- Пример: сбой в Orders API не затронет Payments API, и платежи продолжат обрабатываться.

3. Избыточность экземпляров (Multiple Instances)
- Суть: запуск нескольких копий (экземпляров) ключевых компонентов системы, готовых заменить основные в случае сбоя.
- Как реализовано на схеме: подразумевается, что для каждого сервиса (например, Payments API, Orders API) работают несколько экземпляров.
- Цель: гарантировать непрерывную работу системы — если основной экземпляр падает, его заменяет резервный.
- Преимущества: минимизация простоев, быстрое восстановление после сбоев.

4. Репликация данных (Data Replication)
- Суть: автоматическое копирование данных из основной базы данных (Primary Database) в резервную (Secondary Database).
- Как реализовано на схеме: стрелка с подписью «Replication» между Primary Database и Secondary Database показывает процесс синхронизации данных.
- Цель: защита данных от потери при сбое основной базы. Если Primary Database становится недоступной, система переключается на Secondary Database.
- Особенности: репликация может быть синхронной (данные копируются в реальном времени) или асинхронной (с небольшой задержкой).

5. Аварийное переключение (Failover)
- Суть: автоматический переход на резервный компонент (сервис, база данных) при сбое основного.
- Как реализовано на схеме: если основной компонент (например, Primary Database) выходит из строя, система переключается на Secondary Database (указано: «If a main component fails, you switch to a backup»).
- Цель: обеспечить непрерывность работы системы при отказах ключевых компонентов.
- Ключевые элементы:
- мониторинг состояния компонентов;
- автоматизация процесса переключения;
- минимизация времени простоя (RTO — Recovery Time Objective).

Итог: сочетание этих пяти концепций (балансировка нагрузки, микросервисы, избыточность, репликация и аварийное переключение) позволяет создать отказоустойчивую систему с высокой доступностью, способную быстро восстанавливаться после сбоев и обеспечивать непрерывную работу сервисов.

Представлен проект Just the Browser для чистки браузеров от излишней функциональности, напрямую не связанной с навигацией в Web (прежде всего для чистки функциональности, связанной с AI).

Проект предоставляет скрипты для изменения конфигурации Google Chrome, Microsoft Edge и Mozilla Firefox, и отключения в них сопутствующих возможностей, часто раздражающих пользователей, таких как работа с AI-сервисами, интеграция со сторонними продуктами, отправка телеметрии и показ рекомендованного контента на странице открытия новой вкладки.

Для Windows инструмент представляет скрипт PowerShell, а для Mac/Linux код написан на Shell. Код доступен на github, и там же инструкции по использованию - https://github.com/corbindavenport/just-the-browser

Что такое HTTP Header?
(продолжение в следующем посте)

Что такое HTTP Header?
(продолжение предыдущего поста)

HTTP Header — это метаданные, которые сопровождают HTTP-запросы и ответы, предоставляя дополнительный контекст о коммуникации между клиентом (браузером) и сервером. Они состоят из пар «ключ-значение» и определяют типы контента, учётные данные для аутентификации, поведение кэширования и политики безопасности.

На изображении показаны два типа заголовков: HTTP Request Header (отправляется от клиента к серверу) и HTTP Response Header (отправляется от сервера к клиенту). Разберём их подробнее.

#### 1. HTTP Request Header (заголовки запроса)

Эти заголовки отправляются от клиента (браузера) к серверу и содержат информацию о запросе, возможностях клиента и ожиданиях от ответа. На изображении представлены следующие заголовки:

- Accept: image/webp — указывает типы контента, которые клиент может обработать (в данном случае — изображения в формате WebP).
- Accept-Encoding: gzip — сообщает серверу, какие алгоритмы сжатия поддерживает клиент (здесь — gzip).
- Cookie: name=maxtext — передаёт на сервер сохранённые ранее cookies, чтобы связать запрос с конкретной сессией пользователя.
- Cache-Control: max-age=604800 — задаёт время кэширования ответа (в секундах). Значение 604800 соответствует одной неделе.
- Content-Type: text/html — определяет тип контента в теле запроса (здесь — HTML-документ).
- Content-Length: 30 — указывает размер тела запроса в байтах.
- Referer: https://name.com — показывает URL страницы, с которой был отправлен запрос (помогает серверу понять источник трафика).
- User-Agent: Mozilla/5.0 — идентифицирует браузер или клиентское приложение, отправившее запрос. Сервер может адаптировать ответ под возможности клиента.

#### 2. HTTP Response Header (заголовки ответа)

Эти заголовки отправляются от сервера к клиенту и содержат метаданные об ответе, включая инструкции по обработке данных. На изображении представлены такие заголовки:

- Access-Control-Allow-Origin: \*** — определяет, какие источники (домены) могут обращаться к ресурсу. Звёздочка (*) означает, что доступ разрешён всем.
- **Alt-Svc: h2=":433"; ma=604800 — сообщает клиенту о поддержке альтернативных протоколов (например, HTTP/2 на порту 433) и сроке их действия (ma — max-age, в секундах).
- Cache-Control: max-age=604800 — аналогично запросу, задаёт время кэширования ответа на клиенте.
- Content-Type: image/webp — указывает тип контента в ответе (здесь — изображение в формате WebP).
- Content-Length: 30 — размер тела ответа в байтах.
- Date: Mon, 29 May 2023 17:15:36 GMT — дата и время создания ответа (в формате GMT).
- Set-Cookie: name=alex — сервер отправляет клиенту cookie для сохранения состояния сессии.
- Server: gws — сообщает о программном обеспечении сервера (здесь — Google Web Server, GWS).

#### Итог

- Заголовки запроса помогают серверу понять, что ожидает клиент, какие форматы данных он поддерживает и как обрабатывать запрос.
- Заголовки ответа дают клиенту инструкции по обработке данных (кэширование, тип контента, отправка cookies и т. д.) и содержат метаинформацию о сервере и ответе.

Приложения, созданные с помощью Vibe-кодирования, полны ошибок безопасности

Приложения, созданные с использованием Vibe-кодирования, когда разработчик предоставляет агенту полную свободу действий, скорее всего, будут небезопасными, а популярные агенты, такие как Claude Code, содержат элементарные логические ошибки.
Об этом заявил Ори Дэвид, исследователь из стартап-компании Tenzai, занимающейся вопросами безопасности, который создал три разных приложения, используя одни и те же подробные подсказки с пятью агентами кодирования, используя их стандартные LLM. Исследователь обнаружил примерно одинаковое количество уязвимостей в каждой реализации,


Согласно исследованию, агенты хорошо себя вели в отношении некоторых известных классов ошибок, таких как SQL-инъекции и межсайтовый скриптинг, но плохо справлялись с логикой авторизации и бизнес-логикой.
Примером последнего является то, что большинство агентов позволяли пользователям заказывать отрицательное количество товаров в приложении электронной коммерции и отрицательные цены при создании товаров продавцами.

Среди других распространенных недостатков — уязвимость к подделке запросов на стороне сервера (SSRF) и отсутствие лучших практик в области безопасности, таких как заголовки безопасности.

Агенты программирования не гарантируют безопасность сгенерированного кода, и тот факт, что приложения, созданные с помощью vibe-кодирования, имеют уязвимости в безопасности, не является ни удивительным, ни недостатком самих агентов. Проблема в том, что vibe-кодирование позволяет разрабатывать приложения неквалифицированным разработчикам или тем, кто обладает навыками работы с подсказками ИИ, а не навыками программирования. Если эти простые приложения содержат существенные недостатки, более сложные проекты, вероятно, будут еще менее безопасными.

https://devclass.com/2026/01/15/vibe-coded-applications-full-of-security-blunders/

Авторы Ubuntu протестировали ИИ на своей документации. Главный вывод оказался неожиданным: сэкономленное время съедается проверкой результатов.

Тестировались Claude Sonnet 4.5, Claude Haiku 4.5, GPT-5, GPT-5-mini и Gemini 3 Pro. Первая задача — перевести документацию с британского английского на американский. Claude Sonnet справился на 7 из 10, GPT-5 получил ноль баллов — просто отказался выполнять задачу без объяснения причин. Gemini работал медленно, а потом начал менять слова в обратную сторону. Когда автор указала на ошибку, модель сначала согласилась, затем "поговорила сама с собой" и заявила, что жалоба "необоснована".

На других задачах ИИ показал себя лучше. Claude написал метаописания для 250 страниц, сэкономив команде одну-две недели работы. Оптимизация линкчекера сократила время проверки с 10 минут до полутора — на 85%. Рабочий скрипт для автообновления редиректов тоже получился с первой попытки.

Но в итоге оказалось, что ревью работы ИИ-агентов занимает в два-три раза больше времени, чем ревью работы коллег-людей. Иногда модели делают "случайные и неожиданные вещи" — и чем лучше они справляются в целом, тем выше риск пропустить ошибку.

https://discourse.ubuntu.com/t/ubuntu-server-gazette-issue-11-ai-bots-shall-eat-my-docs/75029

Уровни дизайна системы
(продолжение в следующем посте)