Разработчик Telegram предложил увольнять за код без ИИ. Что стоит за заявлением о 99,9%

Разработчик Telegram предложил увольнять за код без ИИ. Проверяем заявление о 99,9%, новый движок на Rust и исследования влияния нейросетей на скорость работы.

Разработчик клиента Telegram для macOS Майк предложил увольнять программистов, которые пишут код вручную. Его сообщение в публичном чате разошлось вместе с другим утверждением: по его словам, нейросети создают уже 99,9% клиентского кода мессенджера.

Из этих заявлений легко сделать вывод, что Telegram почти полностью написан ИИ, а программисты без нейросетей компании больше не нужны. Но открытые источники дают более узкую картину. Часть технических изменений можно проверить в репозитории, а вот методику подсчёта 99,9% разработчик не привёл.

Откуда взялись 99,9% и кого предложили увольнять

23 октября Хабр пересказал заявления Майка о работе с нейросетями. Разработчик оценил долю сторонников своего подхода среди коллег в 80–90%. Среди примеров назвал перенос клиентского движка MTProto на Rust и другие проекты, созданные с помощью ИИ.

С цифрой 99,9% есть проблема: непонятно, что именно считали. В публикации не объясняется:

• речь обо всём коде приложения или только о последних изменениях;
• долю измеряли в строках, выполненных задачах или как-то иначе;
• учитывали ли код, который разработчики исправили после генерации.

Без этих пояснений число остаётся личной оценкой Майка. По нему нельзя определить, какую часть всего Telegram написали нейросети и сколько работы осталось людям.

Предложение увольнять за ручное программирование тоже прозвучало в публичном обсуждении. Само сообщение не подтверждает, что Telegram ввёл такое кадровое правило или уже увольнял сотрудников по этой причине.

Речь о клиенте Telegram. Серверы мессенджера сюда не относятся

Клиентом называют приложение на телефоне или компьютере. Оно показывает чаты, загружает файлы и отправляет запросы на серверы. Серверная часть обеспечивает работу сервиса. Переписать компонент приложения и заменить серверную инфраструктуру означало бы выполнить две разные задачи.

Даже приложения для одной операционной системы у Telegram могут быть отдельными проектами. На официальной странице клиентов представлены и Telegram Desktop для Windows, macOS и Linux, и нативный Telegram для macOS. Заявление разработчика одного клиента нельзя автоматически переносить на остальные.

Упомянутый Майком MTProto описывает обмен данными между приложением и серверами. В документации протокола выделены форматы запросов, криптографическая часть и транспорт. Новый клиентский движок реализует эти правила в коде. Его появление само по себе не означает, что Telegram изменил протокол или переписал весь мессенджер.

Новый движок на Rust опубликован, но по умолчанию работает прежний

В официальном репозитории Telegram действительно есть клиентский движок MTProto 2.0 на Rust. Он предназначен для iOS и macOS и должен заменять прежний MtProtoKit через общий интерфейс сетевого движка.

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

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

Много сгенерированного кода ещё не означает быструю разработку

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

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

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

• сколько времени уходит на задачу вместе с проверкой и исправлениями;
• проходят ли изменения тесты и проверку коллег;
• как часто после выпуска приходится исправлять ошибки или откатывать обновление;
• отличаются ли результаты на похожих задачах с ИИ и без него.

Для такого сравнения нужны одинаковые требования к качеству. Иначе команда рискует принять быстрый черновик за готовое решение. Счётчик принятых строк эту разницу не показывает.

Исследование о замедлении на 19% тоже требует контекста

В июле 2025 года METR опубликовала эксперимент с 16 опытными разработчиками и 246 задачами. Участники работали в знакомых открытых проектах. С доступом к ИИ они тратили на задачи в среднем на 19% больше времени, хотя сами считали, что ускорились.

Этот результат относился к инструментам и условиям начала 2025 года, преимущественно Cursor с Claude 3.5 и 3.7 Sonnet. Применять его ко всем последующим моделям и способам работы нельзя.

Уже 24 февраля 2026 года METR рассказала о трудностях нового эксперимента. Часть разработчиков не хотела участвовать, если им могла достаться задача без доступа к ИИ. Это искажало выборку. Авторы предположили, что новые инструменты стали полезнее, но признали: собранные данные слабо подходят для точной оценки ускорения.

К тому времени нейросети уже вошли в повседневную работу многих участников профессиональных опросов. По данным Stack Overflow за 2025 год, 84% ответивших использовали или планировали использовать ИИ, а 51% профессиональных разработчиков применяли его ежедневно. При этом 46% опрошенных не доверяли точности результатов, а доверяли 33%. Эти числа описывают участников опроса: использование нейросетей у них вполне сочеталось с недоверием к ответам.