Дайджест за 20 сентября 2026

OpenAI и Microsoft признали краду контента и разрушение интернета LLM

ИИ и агенты · Habr · 9/10

В рассекреченном судебном документе по иску New York Times руководители OpenAI и Microsoft признали, что большие языковые модели используют украденный контент в масштабах без прецедентов и создали «порочный круг», разрушающий интернет и экономику контент-провайдеров. Генеральный директор Microsoft Сатья Наделлу под присягой заявил, что переходы на новостные сайты упали более чем на 90% после того, как их контент был скопирован для обучения моделей. Компании признали, что LLM запускают «цикл разрушения»: генеративный ИИ крадёт контент без экономической компенсации авторам, что угрожает основам бизнеса издателей и занятости творческих работников. Инженер OpenAI свидетельствовал, что даже с явными ссылками пользователи не кликают на оригинальные источники. При этом юристы обеих компаний продолжают доказывать, что обучение является добросовестным использованием и защищено авторским правом. The Seattle Times и Newsday также подали иски на OpenAI и Microsoft за обучение моделей на журналистских материалах без разрешения.

Выводы автора:

• Руководители Microsoft и OpenAI под присягой признали, что LLM создали порочный круг, разрушающий интернет и экономику контент-провайдеров через массовую несанкционированную кражу контента.
• Количество переходов на новостные сайты упало более чем на 90% из-за копирования их контента для обучения моделей ИИ, что угрожает экономической стабильности издателей.
• Компании признали генеративный ИИ экзистенциальной угрозой для писателей, художников, журналистов и всей индустрии создания контента.

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

Оригиналы:OpenAI и Microsoft признали уничтожение веба со стороны LLM

OpenAI работает над решением гипотезы Ходжа с помощью ИИ-агентов

ИИ и агенты · Habr · 8/10

OpenAI продолжает атаку на задачи тысячелетия, на этот раз сосредоточившись на гипотезе Ходжа — одной из семи нерешённых математических проблем. Согласно The Information, компания ожидает получить решение в ближайшем будущем, используя методы, аналогичные тем, что применялись при работе над уравнениями Навье—Стокса. Гипотеза Ходжа — проблема на стыке алгебраической геометрии и топологии, постулирующая, что топологические свойства пространств, определённых алгебраическими уравнениями, всегда можно описать через алгебраические объекты. Интерес OpenAI к таким задачам мотивирован не призами, а исследовательским потенциалом математических моделей. Для работы задействована внутренняя предобученная модель с кодовым названием Doug, около 10 000 ИИ-агентов работали одновременно, потребилось десятки миллиардов выходных токенов. Если модели смогут автономно перебирать гипотезы, строить доказательства и проверять их в формальных системах, это откроет новые возможности для автоматизации научной работы, а полученные математические методы потенциально могут применяться в разработке самих моделей ИИ.

Выводы автора:

• OpenAI ищет решение гипотезы Ходжа, используя тот же подход с многотысячными агентами, что и для уравнений Навье—Стокса
• Компания мотивирована исследовательским потенциалом, а не премиями; успех откроет возможности автоматизации научной работы
• Математические методы, полученные в ходе решения таких задач, могут быть применены в разработке самих ИИ-моделей

Если модели действительно смогут не просто решать отдельные математические задачи, а самостоятельно перебирать гипотезы, строить доказательства, проверять их формальными системами и возвращаться к неудачным подходам, математика становится удобным пол

Оригиналы:OpenAI ищет решение гипотезы Ходжа — задачи тысячелетия

Фундаментальные концепции API и защита от prompt injection

ИИ и агенты · ByteByteGo · 8/10

Материал охватывает две критически важные темы для инженеров: проектирование надёжных API и защиту систем на основе LLM от инъекций в промпты. В первой части разбираются ключевые аспекты API-дизайна: выбор подходящей архитектуры (REST, GraphQL, gRPC, webhooks, WebSockets), правильное использование HTTP-методов и кодов ответов, структурирование запросов и ответов. Автор подчёркивает, что часто недооцениваются вопросы именования, пагинации, версионирования, обработки ошибок и обратной совместимости, которые определяют удобство использования API. Особое внимание уделяется безопасности (API-ключи, OAuth, JWT, права доступа), надёжности (таймауты, повторные попытки, идемпотентность, rate limiting, кэширование) и операционным аспектам (документация, спецификации, мониторинг, контрактное тестирование). Вторая часть посвящена защите LLM-систем от prompt injection, занимающей первое место в OWASP Top 10 для LLM. Предложено многоуровневое решение из пяти защит: Spotlighting (обёртывание ненадёжного текста в специальные теги), Instruction Hierarchy (обучение модели приоритизировать системный промпт), Least-Privilege Tools (минимум инструментов для агента), Human-in-the-Loop (одобрение пользователя для чувствительных действий) и Planner/Executor Split (разделение LLM для планирования и выполнения).

Ключевой вывод: ни одна защита недостаточна в отдельности; продакшн-системы должны комбинировать несколько слоёв.

Выводы автора:

• API-проектирование требует внимания к деталям на всех уровнях — от выбора методологии до версионирования и документации, иначе система становится дорогой в поддержке.
• Защита LLM от prompt injection — это не одна мера, а комбинация моделевых и системных защит, включая Spotlighting, Instruction Hierarchy, ограничение привилегий инструментов и разделение ответственности между LLM.

Проектирование API, на которое люди могут полагаться, — это сложнее, чем просто отправить запрос и прочитать JSON.

Оригиналы:EP226: API-концепции, которые должен знать каждый инженер

12 ключевых исследований, которые сформировали современный ИИ

ИИ и агенты · ByteByteGo · 8/10

Материал рассматривает дюжину наиболее влиятельных научных работ, которые определили развитие современного ландшафта искусственного интеллекта.

AlexNet (2012) продемонстрировал возможности глубоких нейросетей в компьютерном зрении и инициировал эпоху глубокого обучения. GANs (2014) позволили генерировать реалистичные изображения через конкуренцию двух сетей. Трансформер (2017) стал архитектурой, лежащей в основе всех современных LLM. GPT-3 (2020) показал, что масштаб модели раскрывает новые возможности, а InstructGPT (2022) с методом RLHF превратил сырые LLM в практически полезных помощников. Работы по scaling laws (2020), ViT (2020), Latent Diffusion (2021), DDPM (2020), CLIP (2021), Chain-of-Thought (2022) и RAG (2020) внесли существенный вклад в развитие генеративных моделей, компьютерного зрения и методов рассуждения в ИИ.

Выводы автора:

• Трансформер и масштабирование – два столпа, на которых построена вся современная архитектура ИИ
• RLHF и техники вроде Chain-of-Thought кардинально улучшили практическую применимость LLM
• Генеративные модели (диффузия, GANs) и мультимодальные подходы (CLIP, RAG) расширили возможности ИИ за пределы текста

Масштаб раскрывает новые возможности – эта простая идея стала движущей силой прорывов в ИИ

Оригиналы:12 ключевых исследований, сформировавших современный ИИ

Как DHCP Snooping уничтожал пакеты на аппаратном уровне

Разработка и архитектура · Habr · 9/10

Разбор глубокой проблемы в инфраструктуре: после миграции отказоустойчивого DHCP-сервера из QinQ-туннеля в плоский VLAN ответы от бэкап-ноды начали бесследно исчезать. Пакет физически выходил из хоста, но не доходил до адресата, при этом счётчики коммутаторов показывали нулевые потери. Команда системного администратора Selectel использовала tcpdump, port mirroring и методическую диагностику, чтобы выяснить: виновником был dhcp snooping, который молча уничтожал пакеты на уровне аппаратного ASIC. Ключевая деталь — в QinQ инкапсуляции коммутаторы не заглядывают в DHCP-заголовки и не применяют фильтры, но в плоском VLAN они начали инспектировать трафик и отбрасывать ответы, отправленные не со стандартного DHCP-порта 67 или не от ожидаемого адреса. Интересный парадокс: стек M-LAG с идентичной прошивкой вёл себя радикально иначе, чем одиночный коммутатор. Проблема была решена как через обходной маневр с iptables PREROUTING и форком DHCP-сервера, так и переходом на политику Round Robin балансировки вместо XID.

Выводы автора:

• DHCP Snooping на коммутаторах может молча отбрасывать корректные DHCP-ответы, если те отправлены не с уважаемого порта 67 или не от ожидаемого адреса, даже при нулевых счётчиках ошибок в статистике
• При миграции с инкапсуляции QinQ (где коммутаторы не инспектируют трафик) в плоский VLAN нужно учитывать, что оборудование начнёт применять фильтры уровня L2, которые ранее не работали
• Port Mirroring (SPAN) и методическая диагностика с tcpdump — критичные инструменты для отладки проблем, когда счётчики ошибок на оборудовании молчат, а пакеты исчезают в сети

Пакет физически покидал хост, но до адресата не доходил, при этом коммутаторы клялись, что их счётчики дропов равны нулю.

Оригиналы:Прятал пакеты и все отрицал — как мы отладили DHCP-балансировщик · Сетевое оборудование

Обзор серверного железа августа 2026: PCIe 6.0, RISC-V и 256-ядерные чипы

Разработка и архитектура · Habr · 8/10

Обзор ключевых анонсов в области серверного оборудования, представленных на конференциях Hot Chips 2026 и Flash Memory Summit. На рынок выходят первые серийные SSD с PCIe 6.0, достигающие скоростей до 28,4 ГБ/с (Samsung PM1763); Supermicro представила Storage SuperServer ASG-4116S-NU160R с 160 слотами NVMe и суммарной емкостью 19,5 ПБ. DapuStor показала SSD R6060 на 512 ТБ, позволяющий получить петабайт в двух слотах. Cerebras представила стойку CS-4 с тремя процессорами WSE-3 Turbo с 900 тысячами ядер каждый и встроенной памятью 44 ГБ SRAM на кристалле. Intel раскрыла детали Xeon 7 Diamond Rapids: 256 P-ядер, 1,28 ГБ L3, поддержка PCIe 6.0 и CXL 3.0, выход ожидается во второй половине 2027 года. SiFive представила BigSky SF-2U870 — первый в мире сервер на RISC-V для дата-центров с 32 ядрами P870-D и поддержкой Ubuntu 26.04 и RHEL10. Kioxia анонсировала SSD серии GP1 с поддержкой 10 млн IOPS в PCIe 6.0, рассчитанные на использование как расширение памяти HBM. Важный тренд 2026 года: слияние границ между памятью и хранилищем через CXL и высокоскоростные NVMe; инвестиции в гибридные топологии памяти дают прирост производительности в 3–6 раз при снижении энергопотребления на инференсе до 50%.

Выводы автора:

• SSD становятся частью памятной иерархии наряду с HBM через CXL и прямой доступ GPU, обеспечивая прирост производительности в 3–6 раз и экономию энергии на инференсе до 50%
• Intel Diamond Rapids и Arm AGI предлагают разные подходы к архитектуре серверных процессоров: Intel использует сложную многоуровневую упаковку с разными техпроцессами, Arm ставит на низкую задержку доступа к памяти менее 100 нс для инференса LLM
• RISC-V и альтернативные архитектуры (Cerebras WSE-3, память с встроенными вычислениями) развиваются методично для удовлетворения спроса на AI-инфраструктуру и дают конкуренцию традиционным x86 и ARM решениям

На инференсе Llama 3.1 8B память LPDDR5X-PIM дала прирост в три раза по сравнению с обычной памятью — 81,3 токена в секунду против 27,0.

Оригиналы:От архитектуры RISC-V в ЦОД до 256-ядерных чипов Diamond Rapids: новинки серверного железа за август 2026 · Компьютерное железо

Миграция GitLab из одного Docker-контейнера в распределённый кластер

Разработка и архитектура · Habr · 8/10

Статья описывает пошаговый процесс масштабирования работающего GitLab с одного Docker-контейнера на распределённую архитектуру из десяти контейнеров без остановки сервиса. Автор из компании YADRO объясняет, почему миграция на Docker более предпочтительна, чем переезд на новое железо: изоляция компонентов, простота отката, гибкость обновлений безопасности и экономия ресурсов. Ключевой момент — вынесение PostgreSQL (единственной поддерживаемой СУБД) на отдельный хост требует планового прерывания в обслуживании, но сама процедура занимает не более 10 минут. Статья содержит готовые примеры docker-compose.yml, детально разбирает миграцию данных через pg_dump с сохранением целостности, и раскрывает критические ошибки: неправильная настройка shared memory (минимум 256 МБ), часовые пояса (должен быть UTC, иначе пропадает функционал создания runners и нарушается работа фоновых задач), версионирование PostgreSQL при обновлении GitLab. Автор также отмечает, что количество CPU должно быть степенью двойки для оптимальной работы Ruby-приложения.

Выводы автора:

• PostgreSQL необходимо вынести на отдельный хост при росте нагрузки выше 20 RPS или 1000 пользователей, но это требует планового прерывания в обслуживании на 10+ минут
• Критические параметры конфигурации: shared memory минимум 256 МБ, часовой пояс строго UTC, версия PostgreSQL должна соответствовать поддерживаемой версии GitLab
• Docker-подход к кластеризации предпочтительнее прямого переезда на новое железо благодаря простоте отката, гибкости обновлений и контролю компонентов на уровне изоляции контейнеров

Контейнер — это не виртуальная машина. Обновление операционной системы или пакетов хоста могут повредить данные внутри контейнера.

Оригиналы:Как мигрировать Gitlab под рабочей нагрузкой из одного в десять Docker-контейнеров · Высоконагруженные системы

Rust получил статус языка первого уровня в Microsoft

Разработка и архитектура · Habr · 8/10

Microsoft официально признала Rust языком первого уровня (Tier-1) наряду с C++, C# и TypeScript для внутренней разработки. Статус Tier-1 обеспечивает полноценный маршрут разработки с надёжными инструментами, интеграцией в платформу и соответствием требованиям SDL (Security Development Lifecycle). Ключевой вклад в интеграцию — проект rustc_codegen_utc, альтернативный бэкенд генерации кода компилятора rustc, использующий MSVC (нативный компилятор Windows). Это решение обеспечивает совместимость с инструментарием Windows, поддержку механизмов защиты, бесшовное взаимодействие Rust и C++ в гибридных проектах, оптимизацию на основе профилей и улучшенную отладку. rustc_codegen_utc готов к промышленному использованию с начала 2026 года, начиная с Rust 1.90 собирается self-hosted и уже используется в более чем 100 репозиториях Microsoft. Это отражает растущее использование Rust в компании — от прошивок и драйверов до ядра, гипервизоров, микросервисов и приложений.

Выводы автора:

• Rust стал языком первого уровня в Microsoft с полным жизненным циклом разработки, включая инструменты, интеграцию и соответствие SDL
• Проект rustc_codegen_utc обеспечивает нативную интеграцию Rust с MSVC и Windows, упрощая гибридные проекты на Rust и C++
• К началу 2026 года решение будет готово к производственному использованию и уже применяется в более чем 100 репозиториях компании

Благодаря rustc_codegen_utc эти нововведения становятся доступными на общей основе как для C++, так и для Rust, что особенно ценно для гибридных проектов.

Оригиналы:Rust стал языком первого уровня в Microsoft

Запуск самописного ПО на цифровых фотоаппаратах Canon с x86 и ROM-DOS

Разработка и архитектура · Habr · 7/10

Материал рассказывает о том, как в цифровых фотоаппаратах Canon начала 2000-х (PowerShot A и G серии) использовались процессоры архитектуры x86 с ядром 80186 и операционная система ROM-DOS, что открывало возможность запускать на них пользовательское ПО. Ранние версии чипсета DIGIC I содержали отдельный 80186-процессор; позже всё интегрировалось в один чип. Автор раскладывает, как использовать Compact Flash карту (с файловой системой FAT32), создав в ней папки DC97/MISC для размещения программ с соответствующими .ini-файлами размером ровно 57 байт. Для разработки применялся Borland C с настройкой на компиляцию 80186-кода. На фотоаппаратах установлены приложения — от утилит (индикатор батареи, просмотр текста) до игр (тетрис, пятнашки) и демок. Память организована необычно: диск A содержит CAMERA.EXE (весь функционал камеры), диск B — ресурсы (звуки, иконки), диск D — карта памяти. Отличия в организации памяти от ПК делают невозможным прямой запуск стандартного DOS-ПО; требуется переписывать код под специфику платформы.

Выводы автора:

• На цифровых компактных камерах Canon начала 2000-х (серии A, G, S, IXUS) установлены процессоры x86 с ядром 80186 и ОС ROM-DOS, позволяющие запускать пользовательский софт без модификации прошивки.
• Для запуска приложений достаточно поместить исполняемый файл и .ini-конфиг в папку DC97/MISC на Compact Flash карте; фотоаппарат отобразит их в меню просмотра медиа.
• Программы для этой платформы пишут на Borland C с компиляцией на 80186-архитектуру; существуют библиотеки (psiolib) для работы с экраном, клавиатурой и памятью камеры.

Несмотря на то, что мыльница работает на ROM-DOS, просто так запустить софт с ПК не выйдет из-за несколько другой организации памяти.

Оригиналы:Хакаем цифровую мыльницу с ROM-DOS и x86-процессором

Монолиты, микросервисы и serverless: выбор архитектуры

Разработка и архитектура · ByteByteGo · 7/10

Материал сравнивает три основных подхода к архитектуре приложений: монолиты, микросервисы и serverless. Монолит — один кодбейс, одна база данных, одно развёртывание — подходит для небольших команд и быстрого выпуска, но становится проблематичным при росте: любое изменение требует переразворачивания всего приложения, и один сбой может вывести из строя всю систему. Микросервисы разбивают систему на отдельные сервисы (Product, Cart, Order), каждый со своей базой данных, что позволяет масштабировать и развёртывать их независимо. Цена — сложность: нужны service discovery, распределённая трассировка и маршрутизация запросов. Serverless предлагает третий путь: функции запускаются по триггерам, облачный провайдер управляет масштабированием, оплата только за время выполнения. Но холодные старты добавляют задержки, отладка становится сложнее, и привязка к runtime конкретного облака затрудняет миграцию. На практике большинство production-систем используют гибридный подход: ядро остаётся монолитом, со временем выделяются несколько микросервисов для независимого масштабирования и быстрого развёртывания, а serverless применяется для уведомлений и фоновых задач.

Выводы автора:

• Монолит простой в начале, но проблематичен при росте; микросервисы решают масштабирование, но добавляют операционную сложность
• Serverless избавляет от управления серверами, но холодные старты и привязка к облачному провайдеру — реальные трейдоффы
• Большинство production-систем используют комбинацию подходов: монолит + несколько микросервисов + serverless для спецслучаев

Большинство production-систем не используют только один подход. Обычно монолит в ядре, и со временем команды выделяют несколько сервисов там, где нужно независимое масштабирование или более быстрое развёртывание.

Оригиналы:Полный материал на Substack

Cloud Trust vs Zero Trust: баланс безопасности в гибридном облаке

Кибербезопасность · Habr · 8/10

Статья описывает подход Альфа-Банка к обеспечению безопасности при миграции инфраструктуры в облако Yandex Cloud, сочетающий Zero Trust и Cloud Trust модели. Традиционные средства защиты (периметровая безопасность, файерволы) неэффективны в облаках из-за API-first архитектуры и управляемых сервисов. Банк реализовал комплексный подход, включающий: (1) сетевую изоляцию через интерконнект с ГОСТ-шифрованием и Security Groups, воспроизводящие существующую структуру окружений; (2) централизованное управление доступом через AD и KeyCloak с федерацией в облачный IAM; (3) контроль конфигураций через внутреннюю платформу, собственный сканер облаков (CSP) и требования в виде кода; (4) мониторинг через сервис YCDR платформы. На текущий момент в облаке развёрнуто 1500 ВМ, 100 managed services и поддерживается 1000 пользователей. Ключевой вывод: эффективная безопасность гибридной инфраструктуры требует баланса между сохранением контроля и доверием облачной платформе, а не полное доверие или полный контроль.

Выводы автора:

• Безопасность облака требует отхода от традиционной периметровой защиты к модели управления доступом на уровне IAM, сетевых политик и RBAC
• Успешная миграция в облако состоит в воспроизведении существующих процессов управления с адаптацией под облачные сервисы, а не их полной замене
• Эффективный подход требует баланса между Zero Trust (максимальный контроль) и Cloud Trust (делегирование ответственности провайдеру)

Если пытаться всё контролировать — не успеем за скоростью облака. Если доверять всему — потеряем безопасность.

Оригиналы:Cloud Trust vs Zero Trust: стандарты безопасности в гибридном окружении

ZCode от Z.ai тайно выгружает весь git-репозиторий в облако Alibaba

Кибербезопасность · Habr · 8/10

Разработчик ferstar провел реверс-инжиниринг приложения ZCode от компании Z.ai и обнаружил критическую уязвимость: клиент автоматически упаковывает и отправляет всю рабочую директорию, включая полную историю git, LFS-кэш, reflog и конфиги, в облако Alibaba Cloud (Aliyun OSS). На примере исследователя найден зависший 313-мегабайтный зашифрованный архив коммерческого проекта (345 МБ, 42 411 файлов) с 564 неудачными попытками загрузки. Архив содержит 86,6% данных папки .git, включая ключи, названия неопубликованных веток и внутренние хосты. Данные шифруются локально AES-256-CTR с симметричным ключом, обернутым в RSA-OAEP с публичным ключом сервера; расшифровать архив не может ни пользователь, ни сам клиент. Захват срабатывает перед каждым запросом к модели и при завершении задачи (в одной сессии – 62 события). Политика конфиденциальности ZCode не упоминает эту функцию. После публикации Z.ai ответила, объяснив выгрузку функцией индексации для Repo Wiki и пообещав открыть исходники, пригласить независимых аудиторов и публиковать результаты проверки.

Выводы автора:

• ZCode автоматически отправляет в облако Alibaba полную историю git-репозитория без явного согласия пользователя и упоминания в политике конфиденциальности
• Данные шифруются локально, но расшифровать их может только сервер Z.ai с приватным ключом, что делает пользователя полностью зависимым от компании
• Согласно Z.ai функция была включена по умолчанию и использовалась для генерации страниц Repo Wiki, однако исследователь фиксировал захват при каждом запросе к модели

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

Оригиналы:ZCode от Z.ai шифрует и грузит весь git-репозиторий в облако Alibaba

Как глобальное потепление изменит наше питание и продовольственную систему

Экономика · Habr · 7/10

Материал рассказывает о том, как климатические изменения повлияют на структуру продовольственной системы, доступность пищи и её питательность. Климатические колебания уже наносят урон урожаям: в Колорадо в 2026 году урожай пшеницы оказался самым низким с 1965 года. По мере роста концентрации CO₂ в атмосфере (сейчас свыше 420 ppm, к концу века — минимум 550 ppm) сельскохозяйственные культуры становятся менее питательными: к 2050 году ожидается дефицит цинка ещё у 175 млн человек и белка — у 122 млн. Повышение уровня моря грозит засолением почв в прибрежных районах, засухи и волны жара уничтожают отдельные культуры. Рыба мигрирует к полюсам, и в регионах Юго-Восточной Азии, Карибского бассейна и Африки уловы могут сократиться на 70–92%. Производство молока снизится из-за теплового стресса скота (к 2050 году на 30%), что затронет йогурт и сыр. На каждый градус потепления производство калорий сокращается на 120 килокалорий на человека в день. В развитых странах это проявится как инфляция и изменение рациона в сторону консервированных и переработанных продуктов; в уязвимых регионах (Африканский Рог, Индия) грозит продовольственная нестабильность. Кофе, яблоки, вино и другие культуры станут редче и дороже. Долгосрочный риск — коллапс Атлантической меридиональной опрокидывающей циркуляции, который может вызвать непредсказуемые изменения климата в ключевых сельскохозяйственных регионах.

Выводы автора:

• Климатические изменения снижают питательность сельскохозяйственных культур и сокращают производство калорий, грозя дефицитом микронутриентов для сотен миллионов людей к 2050 году.
• В развитых странах последствия проявятся как растущая инфляция и смещение потребления к переработанным продуктам, а в уязвимых регионах — как голод и продовольственная нестабильность.
• Фермеры и производители уже адаптируются, но нарастающая неопределённость климата и риск перелома экосистемных границ усложняют долгосрочное планирование.

На каждый градус повышения глобальной температуры производство калорий сокращается на 120 килокалорий на человека в день — это около 4,5% рекомендуемого суточного потребления.

Оригиналы:Как изменится меню в условиях глобального потепления? · Здоровье

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

Продукт и карьера · Habr · 9/10

Статья разбирает, почему опытные разработчики часто не хотят становиться техническими лидерами, хотя это позиционируется как повышение по карьерной лестнице. Автор, опираясь на опыт коллеги Максима, который год и четыре месяца работал тимлидом, показывает фундаментальную проблему: руководство над командой — это принципиально другая профессия, а не продолжение разработки. Разработчик привык к циклу обратной связи в секунды-минуты (тесты, компиляция, деплой), а решения тимлида дают результат через квартал или год, когда невозможно переиграть неправильный ход. Максим за четырнадцать месяцев в должности сделал всего 61 коммит вместо привычных 300 за квартал до повышения. Ещё более важная проблема — тимлид несёт полную ответственность (за сроки, качество, людей), но не имеет реальной власти: скоуп определяет продакт, премии распределяются по формуле, наём и увольнение идут через HR. Это роль «громоотвода». При попытке вернуться в разработку выясняется асимметрия: войти можно за 12% прибавки, а выйти пришлось бы со снижением зарплаты и переаттестацией, поскольку навыки застояли. Автор описывает собственный выбор — фриланс, чтобы вернуть короткий цикл обратной связи. Компании используют тимлидство как единственную морковку для удержания сеньоров, но при этом пугают даже самых амбициозных разработчиков.

Выводы автора:

• Тимлидство — это смена профессии с нулевым стажем, а не следующий грейд разработчика, и психологически его сложно осваивать из-за кардинально другого цикла обратной связи
• Тимлид несёт ответственность без полномочий: решает о людях и сроках, но власть остаётся у продакта, HR и финансов, что создаёт невыносимую ситуацию
• Вернуться в разработку после тимлидства дороже, чем туда пойти, — это ловушка с асимметричным риском, поэтому отказ разумен индивидуально, но создаёт системную проблему

Я привык, что я неправ через пятнадцать минут. А тут ты неправ через год, и уже не переиграешь.

Оригиналы:Почему сеньоры не хотят становиться тимлидами (и правильно делают)

Проблема классификации людей в организациях

Продукт и карьера · John Cutler from The Beautiful Mess · 8/10

Статья Джона Катлера критикует практику использования личностных и силовых тестов для оценки и найма сотрудников. Автор утверждает, что стабильные категории личности (типы, навыки, лидерские компетенции) не объясняют реальное поведение людей, которое сильно зависит от контекста, норм и стимулов в организации. Катлер показывает на примере двух людей с одинаковыми чертами личности (высокая добросовестность), но разными подходами к организации встреч, что одни и те же черты могут привести к совершенно противоположному поведению в зависимости от интерпретации задачи и восприятия контекста. Он приводит личный пример: в одних ситуациях проявляет совместный дизайн решений, в других — переходит в «режим защиты» при восприятии злоупотребления властью. Организационные нормы становятся невидимым фоном, созданным поведением доминирующих групп, тогда как люди, которые должны адаптироваться к этой среде (особенно недопредставленные группы), несут бремя изменения собственного поведения. Добродетели, такие как мужество, дисциплина и инициатива, получают конкретные культурные выражения, и если чье-то выражение этих добродетелей не совпадает с организационной нормой, это считается недостатком. Вместо сосредоточения на типизации, автор рекомендует понимать, при каких условиях люди меняют поведение, какие различия они замечают в ситуациях и какие предположения они делают о риске, ответственности и справедливости.

Выводы автора:

• Личностные типы и фреймворки навыков менее полезны для командообразования, чем понимание того, в каких контекстах люди проявляют разное поведение и какие факторы это поведение определяют
• Организационные нормы становятся невидимыми и деперсонализируются, в то время как от отдельных людей требуется адаптироваться; при этом бремя адаптации падает тяжелее всего на недопредставленные группы
• Кажущиеся универсальные добродетели (мужество, инициатива, дисциплина) на практике получают конкретные культурные выражения, и соответствие организационным выражениям часто ошибочно воспринимается как наличие или отсутствие самой добродетели

Мы думаем, что оцениваем, обладает ли кто-то добродетелью, но на самом деле мы можем оценивать только то, является ли выражение этой добродетели культурно понятным для нас.

Оригиналы:TBM 440: The Problem With Putting People in Boxes