OpenAI говорит, что 10x-инженеры — это прошлый век. Теперь есть 1000x. А скоро будут миллион-x.

Фраза принадлежит вице-президенту OpenAI в официальном интервью: "There are easily 1,000x engineers now. I don't even know if that's the limit. There may be 1,000,000x engineers coming." То есть он ТОЧНО не шутит и реально так думает.

Давайте на секунду отнесемся к этому серьезно. Да, это тяжело, но давайте пробовать.

1000x-инженер — это один человек, который работает как тысяча. Тысяча! Средняя компания в тысячу инженеров — это годовой фонд оплаты труда в сотни миллионов. И нам говорят, что один парень с Codex заменяет их всех.

В самом OpenAI при этом работает 1200 человек. Заменит ли их всех компания на одного миллион-х инженера?

Дальше — больше. Нам говорят, что Codex написал 90% кода собственного приложения. Любой, кто хоть раз катил что-то в прод, знает: написать код — это 20% проекта. Остальные 80% — понять что строить, не сломать прод и починить когда сломалось. И вот именно этих 80% AI не касается.

Более того — в том же интервью инженеры OpenAI сами признают: новый bottleneck — code review, security, CI/CD. Все то, что требует человеческого суждения. А суждение в 1000 раз не масштабируется. Ни с каким агентом.

Это как сказать, что принтер сделал писателей в 1000 раз талантливее. Печатать быстрее — да. Писать лучше — с чего бы.

Но продавать "1000x" выгодно. Потому что по ту сторону стола сидит CEO, который не понимает ограничений. Он слышит "1000x" и думает: так, у меня 200 инженеров, значит мне нужен один. Или ноль, если агент справится сам. Экономия!

Поэтому всегда важно помнить: у всех заявлений про 1000-х инженеров ровно одна цель — чтобы компании заносили бабки в кассу OpenAI.

// мой ChatGPT 5.4 редактор оценил пост "6/10 как фактологически неуязвимый текст". Интересно, почему? Фактология вся тут, если что.

Самый опасный контракт — тот, который вы не подписывали, а клиент уже считает действующим.

Допустим, у вашего сервиса нет явного SLO. Но вы решили: 99.9% аптайма вам достаточно. Значит, сервис может лежать 2 часа в квартал. Может, это окно под обслуживание. Может — плата за более спокойные релизы. И это нормально.

Но ни клиенты, ни заказчики ничего не знают про ваш SLO. Он живет у вас в голове.

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

А потом сервис падает всего на час.

В вашем мире все хорошо: вы не нарушили SLO ни на копеечку!

В мире вашего клиента (стейкхолдера) все не так. Инженеры уже не молодцы, инженеры — бездельники на зарплате, которые не могут нормальный сервис предоставить. Клиентов нельзя винить — вы ПОКАЗАЛИ им высокий аптайм. Они привыкли к нему. А ваши SLO были только у вас в голове. Их никто не видел.

И ведь это не только SLO касается.

Роадмап «в общих чертах» превращается в обещание. Быстрые фиксы багов — в ожидание, что так будет всегда. Ответы в ночное время — в контракт на круглосуточную доступность. Паттерн один: если что-то хорошее происходит регулярно, оно становится обещанием.

Про «надежда — не стратегия» вы слышали. Так вот мой новый лозунг: «Лучше разочаровать словами, чем подвести делом».

Поэтому: транслируйте SLO заранее. Поставьте «subject to change» на роадмап большими красными буквами. Скажите стейкхолдеру срок, который ему не понравится — но который вы сможете реализовать.

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

Мне нравятся такие статьи. Но они не набирают просмотров — потому что открыто говорят «мы не знаем» вместо тотальной паники.

MIT Technology Review поговорили с экономистом из Чикаго. Вопрос простой: AI реально заберет рабочие места или нет?

Ответ неудобный: мы понятия не имеем.

Смотрите: OpenAI и Anthropic измеряют «exposure» — какой процент задач в профессии AI теоретически может выполнить. Допустим, 50% разработчика может выполнить AI. Выглядит научно. Выглядит как данные. Но это НЕ ТЕ данные.

Это даже не тот вопрос.

Для нас с вами ключевой вопрос такой: если AI делает разработку дешевле, спрос на софт вырастет или нет? Потому что если вырастет сильно — компании наймут БОЛЬШЕ инженеров (или будут больше платить). Если не вырастет — уволят (или станут меньше платить). Это называется эластичность спроса по цене. Ее обычно в районе 10-го класса проходят. Проблема экспертов-паникеров в том, что для большинства профессий данных по эластичности просто не существует.

Высокий exposure ИТ в AI может говорить о том, что инженеров массово сократят. Но так же он может говорить, что миру потребуется в два раза больше инженеров.

Без данных об эластичности спроса мы просто не знаем ответа.

Экономист в интервью говорит: «нам нужен Манхэттенский проект по сбору этих данных.» Задача нерешаема без вливания тонны ресурсов, которые вливать никто не будет. А пока — все прогнозы про AI и работу это гадание. Это весело и интересно (и давайте честно: сейчас мы все это делаем), но к будущему отношения не имеет.

Так что когда в следующий раз кто-то уверенно скажет вам «через 5 лет AI заменит всех» — спросите его: покажи мне эластичность спроса в этой области. Ответом будет тишина.

ИИ — это автомобиль.

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

Человек пройдет везде: овраги, леса, горы; машине нужна инфраструктура. Но при наличии инфраструктуры (и инженеров, которые ее поддерживают), машина может проехать тысячу км в день. И еще тысячу на следующий день. А у человека ножки, мы так не умеем.

Но люди продолжают строить тропинки для людей, мало кто пытается проложить дороги.

Например: заметки со встреч фиксируются в лучшем случае у кого-то в трекере. Но ваш Claude Code не знает, что вы вчера договорились «никогда больше не использовать /api/v2/users». Если вы хотите кататься на ИИ, придется автоматизировать выгрузку таких договоренностей куда-то в базу знаний ИИ.

И кстати, ИИ не умеет ходить по тропкам «эту инфу знает только Вася, спроси у него». Придется выгружать Васю в документацию.

Я своими глазами увидел, на что способен ИИ, которому люди проложили дорогу. Он за 2 дня сделал то, что человек делал бы два месяца: переписал наш сервис на питон вместо шарпов.

Что вновь возвращает меня к мысли, которую я повторяю последний год: ИИ нас не заменит.

Мы для него еще даже дороги не проложили.

Ой да кому мы нужны...

И другие фразы, с помощью которых можно забить на ИБ.

Правда, есть нюанс.

Сегодня Booking.com подтвердил утечку клиентских данных: имена, email, адреса, телефоны и детали бронирований. Пострадавших уже предупреждают о фишинге — в том числе через мессенджеры, с точными деталями поездки. Сколько людей затронуто, компания не раскрывает.

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

Начните завтрашний день с ревью ИБ тикетов вашего проекта.

Потому что некоторые риски любят, когда их называют «не срочно».

Признавайтесь, чей ИБ отдел?

Приносите на работу себя целиком.

Красивый тезис, но очень плохой совет.

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

Не беспокойся о мнении окружающих, будь честен с собой и окружающими, будь НАСТОЯЩИМ собой, будь ЦЕЛЫМ собой. И всегда придерживайся своих ценностей!

Давай прям по частям разбирать, что ли.

Всегда будь честен с собой и другими!

Посыл интересный, но проверять не рекомендую. Например, Стив Джобс честно говорил «this work is shit» (цитата) и вряд ли сотрудники были в восторге от такой честности. Если работа реально is shit, все равно дать аккуратную ОС. Вам ведь нужно чтобы человек сделал работу хорошо, а заявление про is shit его демотивирует, хотя и будет честным. Не рекомендую.

К тому же, когда Стив Джобс говорит человеку «this work is shit», человек идет переделывать. Если так говорит не Стив Джобс, человек совершенно справедливо идет в HR.

Не парься, что о тебе подумают!

Прикольно звучит, но не очень прикольно работает. Я работал с людьми, которые на мою обратную связь отвечали «Ну вот такой я человек!». Причем обратная связь была, что не надо прям в открытую говорить стейкхолдерам, что они тупые. Я не утрирую, кстати. Мне потребовались месяцы, чтобы нарастить на мощные харды человека софт-скиллы. Но сначала мне пришлось воевать с позицией «Ну вот такой я человек!»

Всегда следуй своим ценностям!

Очень опасная позиция для лидера. Я понимаю, что мои ценности кончаются там, где заканчиваюсь я сам. Например, моя ценность — работа. Много работы, меньше отдыха. Если я буду следовать своим ценностям, я буду строить команду трудоголиков. Но загонять людей в переработки из-за собственных ценностей неправильно .

Поэтому для себя я думаю вот как:

Приноси на работу не всего себя, а лучшую версию себя.

И у меня для вас есть личная история.

Зимой 2019 года мне было довольно фигово из-за некоторых проблем.

Но я уже был тимлидом и где-то на уровне ощущений понимал, что нельзя тащить мое уныние в команду. Так что я загуглил примерно такое: «как перестать быть унылым, если очень надо». Гугл ответил: если ты будешь улыбаться, через 5-10 минут тебе станет нормально. Звучало странно, но проверка ничего мне не стоила. И я попробовал.

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

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

Именно это я и называю «приносить лучшего себя». Такая аутентичность мне нравится.

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

ЗАНЯТОСТЬ = ПРОГРЕСС

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

Занятость полезна сотруднику: она как минимум служит индульгенцией перед руководством. «Я занят» означает, что я отрабатываю свою зарплату. В жалобе «Я занят» порой сквозит гордость; человек сигнализирует, что востребован и важен, его жизнь наполнена делами.

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

Единственный, кто не рад тотальной занятости — это компания.

Потому что когда все заняты, некому задать очень громкий вопрос: «Господа, а не херню ли мы тут делаем?» Этот вопрос не влезет между встречами. Ему нужно уделить время.

А у занятого человека нет времени на сомнения.

Я своими глазами видел что происходит, когда у команды нет этого времени (всем примерам 3 года и более, если что):
• Команда полгода долбила по инерции задачи, которые приносили МЕНЬШЕ денег, чем компания тратила на содержание команды. Но все были заняты.
• Менеджер соглашался на все влеты от стейкхолдеров и в итоге тратил весь ресурс команды на влеты. Почти за год такой работы ни одного крупной фичи команда не выкатила, только небольшие хотелки больших начальников.

Если вы — руководитель, у вас ОБЯЗАНО быть время на подумать. В идеале, вы должны обеспечивать его и вашим сотрудникам.

Нет никакой разницы, насколько много вы работаете, если вы работаете не в ту сторону.

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

Аргументы и камни

Представьте, что вы пишете стратегию. Хорошей идеей станет добавить в начало блок «проблемы» или «вызовы» — ведь хорошая стратегия обязана отвечать на вызовы или решать проблемы.

Вопрос: сколько проблем перечислять?

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

Но это неправда.

Рационально посыл верный: больше аргументов — лучше. Но Канеман давно доказал: человек — не рациональный агент. По крайней мере, не всегда. Если аргументов будет слишком много, они рассеят внимание ваших слушателей и приведут к обратному результату. Люди не складывают аргументы как числа в таблице.

После определенного порога новые аргументы уже не усиливают позицию, а размывают ее.

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

Поэтому я всегда советую делать так:
1. Соберите все аргументы (проблемы, вызовы и так далее), чем больше — тем лучше. Это ваши камешки.
2. Кластеризуйте аргументы по смыслу. Это будут ваши валуны.
3. Позже в тексте раскройте каждый аргумент. Иначе ваши валуны останутся полыми и не пробьют стену сомнения.

Давайте для примера.

Вот было:

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

А вот стало:
• Мы медленно поставляем изменения и скорость снижается
• Наша система стала хрупкой: падает каждый третий релиз
• Команда не масштабируется, новые люди въезжают в проект по полгода

Три булыжника такого калибра помогут проломить стену «да вроде все нормально в команде».

Я попробовал Claude/GPT/etc и сделал за вечер то, что раньше целая команда делала неделю

В том или ином виде я эту фразу слышу по всей индустрии. И я ее искренне не люблю по двум причинам:
• Это правда
• Это не вся правда

Где правда: Claude или Codex действительно позволяют одному человеку собрать за вечер то, на что раньше у команды уходили дни. Такую правду любят рассказывать на конференциях или строить на ней крайне амбициозные планы. Полезная правда.

Но есть ма-а-аленький нюанс.

Полностью цитата должна звучать так:

Я за вечер собрал прототип, который целая команда собирала неделю

Потому что в 95% случаев рассказчик имеет в виду «У меня получилось собрать первое рабочее решение». Но если вы когда-то писали код, вы знаете, что между «первым рабочим решением» и «можно катить решение в прод» пропасть, которая доверху заполнена коммитами final_fix, final_final_fix и pls work I want home.

И давайте вспомним наше любимое правило 80 на 20: 20% усилий приносят 80% результата.

Да, в продукте нам часто не нужно 100% фичи. Но если вы катите в прод, вам нужно полностью пройти минимальный порог надежности: тесты, безопасность, интеграции, мониторинг, откат, поддержку. Через пропасть нельзя перепрыгнуть на 80%.

Поэтому мне не нравится начальная цитата. Она скрывает необходимость перепрыгивать пропасть полностью. «Напилить MVP за вечер» != «выполнить работу целой команды».

Задача инженерных лидеров (я говорю про всех лидеров, а не только руководителей) сделать так, чтобы ИИ в компании помогал перепрыгивать пропасть полностью. А для этого ИИ должен прорасти вообще везде: в ревью, в архитектурные решения, в CI/CD, релизы, тушение пожаров и много другое.

Потому что собирать первую итерацию умеет любой ИИ-агент. Но агент не сможет трансформировать свою организацию так, чтобы ИИ (почти) автономно решал задачи за пределами MVP.

Если вы думали, что найм сломан, то у меня для вас новость.

Его скоро доломают окончательно.

Шведский стартап Fika прям щас строит платформу для собеседований. Но так как мы живем в 2026-ом, то без ИИ не обойдется: на платформе соискателя будет собеседовать ИИ. И не просто собеседовать, а на обязательном видео-звонке.

Работать будет так:
1. Вы обнаруживаете в себе тягу в скором времени поменять рабочее место
2. Вы откликаетесь на вакуху в линкедине
2. Fika читает ваш профиль и составляет список вопросов под вас
3. Fika назначает вам звонок
4. На звонке вас опрашивает Gemini-модель.

Но это еще не самое проклятое.

Самое проклятое в финале: Fika нарезает интервью на ШОРТСЫ и отправляет работодателю. Непонятно, на что расчет: типа, зумеры-руководители не смогут посмотреть 10 минут интервью не через шортсы?

Fika подняли 4 миллиона долларов на пре-сид раунде. Венчурные дядьки такие суммы пацанам с улицы не дают. Это не мелочь. По меркам венчура в 2026 — это прям выше среднего. Венчурные дядьки почуяли иксы, поэтому стартап точно продолжит расти в ближайшее время.

Но — поводов расстраиваться нам с вами я не вижу.

Fika может стать (а может и не стать) хорошим инструментом в потоковом найме. Но до ИТ оно вряд ли докатится. Fika это решение для массового найма с похожими требованиями. Для найма кадров с высокой квалификацией, использовать Fika — стрелять себе в ногу.

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

Но системно Fika у нас не приживется.

Сами подумайте: если компания начинает общение с хорошим инженером через заход «Поговори с нашим ИИ, а мы потом посмотрим нарезку шортсов с тобой» — захочет ли инженер тратить время на такую компанию?

Вот и я думаю, что нет.