Внедрение ИИ приведет к найму специалистов начального уровня, считают руководители компаний

Генеральные директора крупных публичных компаний считают, что распространение искусственного интеллекта приведёт к постепенному возвращению найма специалистов начального уровня. Об этом свидетельствуют результаты опроса топ‑менеджеров, проведённого консалтинговой компанией Teneo.

В исследовании приняли участие более 350 генеральных директоров публичных компаний с годовой выручкой свыше $1 млрд, а также около 400 крупных институциональных инвесторов. 67% респондентов заявили, что внедрение ИИ приведёт к росту найма на начальные позиции уже в следующем году. При этом 58% опрошенных сообщили о планах по найму специалистов на сеньорские и управленческие позиции.

Согласно докладу Teneo, рост найма может быть обусловлен стремлением компаний увеличить число сотрудников, непосредственно работающих с технологиями искусственного интеллекта. Кроме того, по мере внедрения ИИ и автоматизации процессов происходит трансформация и перераспределение существующих ролей. В результате ИИ не уничтожает рабочие места, а скорее видоизменяет их, отмечают в Teneo.

https://www.businessinsider.com/ai-hiring-comeback-entry-level-jobs-ceo-teneo-survey-2025-12?IR=T

Сравнение Rust vs C++

Наглядно про файловую систему в Linux

Обязательную идентификацию владельцев доменов через «Госуслуги» утвердили в Госдуме

Комитет Госдумы по информполитике рекомендовал к принятию законопроект, вводящий обязательную идентификацию владельцев всех доменов в зонах .ru и .рф через «Госуслуги» и создание правительственного реестра аккредитованных регистраторов.
Вступить в силу нормы о новом порядке регистрации доменов могут с 1 сентября 2026 года.

https://www.kommersant.ru/doc/8293585

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

Что такое дескриптор процесса в Linux
(продолжение предыдущего поста)

Дескриптор процесса (process denoscriptor) в Linux — это централизованная структура данных (task_struct), которая содержит всю необходимую информацию о процессе и которая позволяет ядру Linux эффективно управлять процессами, их ресурсами и взаимодействием в многозадачной среде.. Он служит «паспортом» процесса: хранит его состояние, параметры, ссылки на ресурсы и связи с другими процессами и структурами ядра.

#### Структура дескриптора (task_struct)

На изображении представлена схема дескриптора процесса. Он состоит из множества полей, среди которых:

1. `state` — текущее состояние процесса (например, выполняется, спит, завершён).
2. `*stack` — указатель на стек процесса (область памяти для хранения локальных переменных и вызовов функций).
3. `flags` — битовые флаги, определяющие свойства процесса (например, приоритет, режим выполнения).
4. `*mm` — указатель на структуру mm_struct, описывающую виртуальную память процесса (включая таблицу страниц и PGD — Page Global Directory).
5. `exit_code` — код завершения процесса (используется для передачи статуса завершения родительскому процессу).
6. `*user` — ссылка на user_struct, содержащую информацию о пользователе, запустившем процесс.
7. `pid` — идентификатор процесса (Process ID), уникальный в рамках системы.
8. `*files` — указатель на files_struct, описывающий открытые файлы и ресурсы (файловые дескрипторы).
9. `*parent` — ссылка на дескриптор родительского процесса (важно для иерархии процессов).
10. `*signal` — указатель на signal_struct, хранящую информацию о сигналах, направленных процессу.

#### Связи с другими структурами ядра

Дескриптор процесса не ограничивается только внутренними полями — он содержит указатели на другие ключевые структуры ядра:

- `mm_struct` — управляет виртуальной памятью процесса, включая таблицы страниц (pgd — указатель на глобальную директорию страниц) и связь с физической памятью (pagedir[]).
- `user_struct` — хранит данные о пользователе (UID, GID и т. д.), от имени которого запущен процесс.
- `files_struct` — описывает открытые файлы, сокеты и другие ресурсы, доступные процессу.
- `signal_struct` — содержит информацию о сигналах (например, SIGTERM, SIGINT), которые могут быть отправлены процессу.

#### Зачем нужен дескриптор процесса?

1. Управление процессами: ядро использует дескриптор для планирования, переключения контекста, синхронизации и завершения процессов.
2. Изоляция ресурсов: каждый процесс имеет свой дескриптор, что обеспечивает защиту памяти и ресурсов.
3. Взаимодействие процессов: через поля *parent, *signal и другие реализуется связь между процессами (например, передача сигналов, ожидание завершения дочерних процессов).
4. Учёт и аудит: дескриптор хранит данные для логирования (PID, пользователь, код завершения).

65% разработчиков используют ИИ-ассистенты. Теперь некоторые не могут кодить без них

Считается, что программирование с использованием ИИ обеспечивает разработчикам программного обеспечения беспрецедентный прирост производительности.
Например, согласно опросу Stack Overflow, около 65% разработчиков используют инструменты на основе ИИ еженедельно. Это связано с возможностью быстрого написания тестов, исправления ошибок и объяснения незнакомого кода.

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

Так, в статье приводится пример инженера из компании Companion Group по имени Лучано Нойен, который активно пользовался ИИ-ассистентами на основной работе — там их предоставляли бесплатно. Но когда он начал сторонний проект без доступа к этим инструментам, то обнаружил, что не справляется с задачами, которые раньше решал автоматически. "Я чувствовал себя таким тупым, — признается Нойен. — Вещи, которые раньше были инстинктом, превратились в ручную, иногда даже громоздкую работу". По его мнению, сохранить навыки можно только как спортсменам — регулярно практикуя базовые упражнения.

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

В добавок по прежнему существуют большие технические ограничения при использовании ИИ: большие языковые модели имеют ограниченную рабочую память ("контекстное окно"), что затрудняет обработку крупных кодовых баз и ведет к ошибкам.

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

https://www.technologyreview.com/2025/12/15/1128352/rise-of-ai-coding-developers-2026/

Архитектурный паттерн Command Query Responsibility Segregation (CQRS)
(продолжение в следующем посте)

Архитектурный паттерн Command Query Responsibility Segregation (CQRS)
(продолжение предыдудщего поста)

→ CQRS — это архитектурный шаблон, разделяющий операции чтения (запросы) и операции записи (команды).
→ Команды изменяют состояние системы.
→ Запросы лишь считывают данные и никогда их не модифицируют.
→ Такое разделение позволяет каждой из сторон масштабироваться, оптимизироваться и развиваться независимо.

Основные понятия

→ Команда — действие, изменяющее данные (*CreateOrder*, *UpdateProfile*).
→ Запрос — запрос, извлекающий данные (*GetOrderById*, *ListUsers*).
→ Модель записи — обрабатывает бизнес‑правила, валидацию и изменения состояния.
→ Модель чтения — оптимизирована для быстрого извлечения данных (часто денормализованная).

Как это работает

→ Клиент отправляет команду → Обработчик команд → Модель записи → База данных.
→ Клиент отправляет запрос → Обработчик запросов → Модель чтения → Оптимизированное хранилище для чтения.
→ Команды и запросы используют раздельные пути и могут работать с разными базами данных.

Простая аналогия: банковская система

→ Команды = Внесение или снятие денег (изменяет баланс).
→ Запросы = Проверка баланса счёта или истории операций (только чтение).
→ Вы не обновляете баланс при его проверке — обязанности чётко разделены.

Преимущества

→ Повышенная производительность для систем с высокой нагрузкой на чтение.
→ Независимое масштабирование операций чтения и записи.
→ Чёткое разделение обязанностей.
→ Упрощённая оптимизация моделей данных для конкретных сценариев использования.
→ Хорошая совместимость с системами, управляемыми событиями.

Недостатки

→ Повышенная сложность архитектуры.
→ Возможная несогласованность данных между моделями чтения и записи (согласованность в конечном счёте).
→ Больший объём инфраструктуры для управления (несколько моделей, хранилищ).
→ Избыточность для небольших или простых приложений.

Лучшие практики

→ Применяйте CQRS только тогда, когда сложность оправдана.
→ Сочетайте CQRS с Event Sourcing, если требуется аудит.
→ Делайте команды сфокусированными на задаче и явными.
→ Оптимизируйте модели чтения под нужды интерфейса, а не ради чистоты домена.
→ Грамотно обрабатывайте возможную несогласованность данных в интерфейсе.

Когда применять

→ Системы с существенным дисбалансом операций чтения и записи.
→ Сложные бизнес‑домены с множеством правил.
→ Приложения, требующие масштабируемости и высокой производительности.
→ Системы, управляемые событиями, или системы на основе микросервисов.

Генеральный директор Amazon Web Services Мэтт Гарман назвал «одной из самых глупых идей» сокращение вакансий для начинающих разработчиков из‑за внедрения ИИ.

По словам Гармана, полная замена младших сотрудников искусственным интеллектом не имеет никакого смысла, поскольку такие сотрудники зачастую лучше разбираются в инструментах ИИ ввиду своей молодости. Нынешние выпускники вузов выросли в эпоху новых технологий, поэтому им проще адаптироваться, говорит гендиректор AWS. Как правило, молодые специалисты находят новые быстрые способы написания кода и выясняют, как добиться наилучших результатов работы от ИИ‑агентов.

Гендиректор AWS также раскритиковал попытки экономии за счёт младших сотрудников. Обычно начинающие разработчики получают гораздо меньшую оплату труда, и их увольнение не принесёт компании существенной экономической пользы, говорит Гарман. По его мнению, оптимизацию процессов в компании следует проводить, учитывая также и работников старшего звена, которые получают более высокие зарплаты.
Помимо этого, Гарман считает, что подобный опыт сокращения начинающих разработчиков разрушает систему подготовки кадров

По слова гендиректора AWS, руководители компаний, которые заменяют начинающих разработчиков искусственным интеллектом, таким образом демонстрируют неспособность к долгосрочному планированию. Полагающаяся лишь на инструменты ИИ компания в конечном итоге столкнётся с нехваткой персонала, говорит Гарман.

https://www.wired.com/story/the-big-interview-podcast-matt-garman-ceo-aws/

Символы ASCII вместо графики как основа для создания видеоигр

Система видеонаблюдения на основе ИИ ввела режим изоляции в средней школе имени Лоутона Чайлза в штате Флорида после того, как приняла за оружие кларнет ученика.
Прибывшая полиция объявила о прекращении режима изоляции, указав, что детям ничего не угрожало.

Директор школы Мелисса Лаудани заявила, что в учебном заведении действует многоуровневая безопасность, включая автоматизированную систему, которая обнаруживает потенциальные угрозы. По её словам, ученик держал кларнет как оружие, что привело к срабатыванию системы.

Аналогичный случай произошел в штате Мэриленд: там школьная система безопасности на базе ИИ приняла за пистолет пачку чипсов Doritos в руках старшеклассника. В двух этих случаях системы позволили ИИ принять решения без какого-либо вмешательства со стороны человека.

https://futurism.com/future-society/ai-surveillance-school-clarinet

Шпаргалка по командам для тестирования и отладки сети в Windows, Linux и MacOS

C++: Расположение данных в памяти и директивы компилятора
(продолжение в следующем посте)

C++: Расположение данных в памяти и директивы компилятора
(продолжение предыдущего поста)

Визуализация показывает, как три директивы компилятора C++ существенно изменяют размер и организацию простой структуры данных, управляя выравниванием и добавлением отступов в памяти.

Разница между стандартным (8 байт) и упакованным (5 байт) расположением критически важна для производительности и передачи данных!

Варианты расположения данных:

- Стандартное (Default): естественное выравнивание. После типа char добавляются 3 байта отступа, чтобы выровнять тип int по границе в 4 байта.
Размер: 8 байт.

- Упакованное (Packed): отступы не добавляются. Тип int начинается сразу после char, но для доступа к невыровненным полям может потребоваться несколько инструкций процессора — это сводит на нет выгоду от экономии памяти.
Размер: 5 байт.

- Выровненное (Aligned): заданное выравнивание (например, aligned(16) или aligned(32)) может добавлять значительные отступы в конце, чтобы гарантировать, что последующие структуры начинаются с требуемой границы.

Почему расположение данных компилятором имеет значение:

- Сетевые протоколы: использует упакованные структуры для минимального «формата передачи», чтобы не отправлять лишние байты отступов.

- Аппаратные интерфейсы: применяет конкретное выравнивание для ввода‑вывода с отображением в память, когда аппаратное обеспечение ожидает данные на определённых границах.

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

- Кроссплатформенная совместимость: обеспечивает согласованное размещение памяти при компиляции кода на разных архитектурах.

Обобщённые инвертированные индексы (Generalized Inverted Indexes / GIN)
(продолжение в следующем посте)

Обобщённые инвертированные индексы (Generalized Inverted Indexes / GIN)
(продолжение предыдущего поста)

Generalized Inverted Indexes (Обобщённые инвертированные индексы или GIN) — мощный инструмент СУБД, в частности, в Postgres.

Они отлично подходят для инвертирования типичного сценария использования индексов.

Вместо сопоставления «строка с ID 2 содержит значение „become a database expert“» вы переворачиваете это так: «токен „database“ сопоставляется со строками с ID 1, 2 и 3, а токен „expert“ — со строкой с ID 2».

Индексам GIN передаётся набор значений для каждой строки, которую вы хотите проиндексировать. Каждое уникальное значение становится ключом в индексе и сопоставляется с набором CTID (идентификаторов строковых кортежей), содержащих это значение.

У такого подхода есть несколько вариантов применения, один из которых — полнотекстовый поиск! В MySQL есть специальный тип индекса FULLTEXT, тогда как в Postgres для создания аналогичной функциональности используются более универсальные индексы GIN. Как это сделать?

(а) Добавьте в таблицу столбец tsvector:

CREATE TABLE post (
    author TEXT,
    publish_date DATE,
    content TEXT NOT NULL,
    search_vector tsvector);

(б) Заполните его лексемами (нормализованными словами):

UPDATE post
    SET search_vector =
    to_tsvector('english', content);

(в) Создайте индекс, используя лексемы в качестве ключей:

CREATE INDEX post_search_idx
    ON post USING GIN(search_vector);

(г) Выполняйте запросы!

SELECT * FROM post
    WHERE search_vector @@
    to_tsquery('english', 'database & expert');