Робот, заменяет человека

Трансляция идёт уже третий день. Робот Helix-02 от компании Figure AI непрерывно работает на конвейере. Переворачивает посылки этикеткой вниз для последующего автоматического сканирования.

https://www.youtube.com/live/luU57hMhkak?si=qv9jkPg-INvkNB9J

Вышел трейлер документалки C++: The Documentary

Сам фильм выходит 4 июня 2026 года. Фильм спонсируется HRT (Hudson River Trading). Это топовая трейдинговая компания, специализирующаяся, в том числе, на high frequency трейдинге.


Сам трейлер:
https://youtu.be/NXwTRzywDSk?si=lmNOn_VyeXJTvDwj

Токенмаксинг

Ещё один свежий buzzword. Это когда сотрудники соревнуются в использовании AI-токенов, часто прибегая к бесполезному использованию AI ради самой метрики. Понятие возникло в Meta, но тренд распространился на многие компании, особенно на Amazon. Я работал в обеих компаниях.

Смотри также: Coffee Baging

Update по замене программистов при помощи AI

Заменяет ли AI программистов в 2026 году?
Краткий ответ: нет, но с нюансами.

С момента релиза ChatGPT прошло уже 3.5 года. За это время как сами модели так и тулы на основе этих моделей проделали большой путь.
Если в 2023 это был просто какой-то бесполезный прикол. То благодаря появлению CoT (Chain of Thought) и RLHF(Reinforcement Learning from Human Feedback) в 2024 стало понятно, что это как минимум может заменить собой поиск в интернете и Google Search под большой угрозой. Кроме того, для кода это стало заменять StackOverflow, Google поиск и автокомплиты в среде разработки.
В 2025 OpenAI со своим ChatGPT стало тормозить в развитии. Релиз ChatGPT 5.0 оказался разочарованием. Существенного прогресса по сравнению с предыдущей версией не было. Казалось, что хайп по AI начинает проходить. Круговые сделки между Oracle, Open AI, Microsoft раздували AI Bubble. И на сентябрь-октябрь 2025 казалось, что вот вот пузырь лопнет и хайп закончится.

Но тут вырвались сильно вперед Google Gemini и Anthropic Claude. А с релизом Claude Opus 4.6 в феврале 2026 года стало ясно, что автоматизация написания кода уже практически случилась.

Но, что важно, Claude Code + Opus >=4.6 могут помочь с написанием кода, но все еще не могут заменить программиста. Он все еще требует постановки задач, уточнения требований, ревью написанного кода. Кроме того, программист начиная с уровня Middle делает много чего другого, кроме написания кода. Это создание технической стратегии развития продукта, фичи, компоненты. Это создание и овнинг роудмапа. Это декомпозиция сложных задач и проектов. Это определение и устранение технических и организационных ботлнеков проектов. Это архитектура и дизайн продуктов и решений. Это обсуждение и согласование требований, технических решений. Это обнаружение и устранение конфликтов. Это написание и ревью кода. Это тестирование и мониторинг кода, фич и т.д. Это деплоймент и саппорт. Это документирование. Это менторинг и обучение. Это хайринг. И т.д.

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

Что по AI-собеседованиям?
Во многих компаниях сейчас стали заменять один из стандартных leetcode-style кодинг раундов на AI-coding. В том числе и в Мете. Раунд длится 60 минут вместо 45 минут. При этом задача одна, вместо двух. Но в ней несколько под-заданий. Например, пофиксить баг, реализовать функционал, написать тесты. У вас уже будет какое количество написанного кода до вас. А также могут быть файлы с данными. Обычно, это файл с тестами, файл с данными и пару файлов с кодом. При этом вам разрешают пользоваться строенным LLM в среду разработки, в которой вас будут собеседовать. Формулировка задач при этом более практичная, чем стандартные leetcode задачи. Но по факту, это не просто API с бойлерплейт кодом и перекладываением джейсонов. С чем в реальности работает программист на работе. Это все равно так или иначе задача на использование структур данных и алгоритмов. Кроме того, просто переадресовывать вопросы интервьюера LLM и копировать код не получиться. Придется разбираться с постановкой задачи, существующим кодом, алгоритмами и структурами данных. LLM просто может вас ускорить и помочь ускорить процесс написания кода.

Что будет в будущем?
Если экономика использования AI для кодирования сойдется, то написание кода будет существенно автоматизировано. Пока даже с этим есть проблемы. Например, Uber недавно израсходовал годовой бюджет на Claude Code за 4 месяца. Microsoft также перешли на свой AI, в том числе потому, что Claude Code дорогой. Но если по деньгам будет все ок. То кодирование с помощью AI станет новой нормой. Но при этом до замены программистов все еще далеко. AI просто существенно повлияет на профессию. При этом уметь программировать, знать особенности языка программирования, структуры данных, алгоритмы все еще будет необходимо. Что будет через 2-5 лет сказать очень сложно. Все очень быстро меняется.

Смотри также:
LLM vs программисты

Uber COO Андрю Макдональд про AI

Uber израсходовал годовой бюджет на AI за несколько месяцев. При этом COO Uber в интервью рассказал, что пока сложно установить связь между реальным увеличением производительности (увеличение числа заде́ливеренных фич или рост выручки) и использованием AI. То есть использование AI растёт, расходы на AI растут, но нет увеличения выхлопа от этого. По крайней мере, пока сложно установить связь между расходами на AI и ростом производительности.

https://youtube.com/shorts/GZFCSyjunZI?si=eDi4fcd3RV3PELrC

Вышла документалка про создание C++

Трейлер: https://youtu.be/NXwTRzywDSk?si=3aEmsgWoZXUjA2Hk

Документалка: https://youtu.be/lI7tMxzSJ7w?si=aSSf8X7ZWxZpH_CY

На том же канале много других прикольных документалок

1) IntelliJ IDEA. Про создание, возможно, лучшей среды разработки для Java.

Трейлер

Фильм

2) Spring. Про создание одного из самых популярных фреймворком для Java.

Трейлер

Фильм

3) Java. Про создание языка программирования Java. Пока только трейлер. Фильм должен выйти летом этого года.

Трейлер.

Exit стратегия ранних инвесторов в Open AI, Anthropic и Space X заключается в использовании пенсионных накоплений американцев

Такая дискуссия разворачивается в преддверии самых масштабных IPO в истории. В этом году на IPO выходят SpaceX, OpenAI и Anthropic. Ранние инвесторы вкладывали колоссальные деньги в эти компании по астрономическим оценкам. Все три компании глубоко убыточные. Revenue (доход) измеряется десятками миллиардов долларов в год. При этом оценка капитализации в триллионах долларов.
Выход на IPO — это один из вариантов вернуть инвестиции и заработать на них.

Но что необычного сейчас происходит?

Крупные индексы, вроде Nasdaq, Russell 1000, S&P 500, изменили правила включения компаний специально под эти 3 компании. Они сократили время включения до недель и даже дней, вместо месяцев или даже года. Кроме того, S&P 500 исключил правило, что для включения компании в индекс нужно, чтобы компания была прибыльной.

То есть,

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

Но как это связано с пенсиями в США?

В США существенная часть пенсий поступает от так называемых инвестиционных счетов 401(k). Работник может откладывать часть своего дохода на специальный инвестиционный счёт. Например, 5%. Часто работодатель может добавить столько же. То есть вы можете откладывать 10% своего дохода на инвестиционный счёт. Причём вы откладываете процент дохода до уплаты налогов. То есть то, что вы туда откладываете, идёт в обход уплаты налогов.
И когда вы перечисляете туда деньги, вы можете выбрать индексы, в которые вы инвестируете. Снять деньги со счёта до достижения пенсионного возраста очень сложно, и придётся платить штраф за это.

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

Соответственно, ранние инвесторы могут быстро продать свою долю и выйти по астрономической цене за счет пенсионных денег американцев.

Это вызвало широкие обсуждения в последнее время. И S&P 500 уже отказался от упрощенных правил для этих трех компаний. Но Nasdaq и Russell 1000 — нет.

Более того, под соусом SpaceX нам продают ракеты, но в реальности туда включили X.AI (создатель Grok), который является глубоко убыточным AI-бизнесом.

Всё это, совместно с разговорами про токенмаксинг и бесполезными расходами на AI (не видна польза от внедрения AI, видны только астрономические расходы), снова поднимает тему про AI Bubble.

Почему самые высоконагруженные веб приложения мира это не всегда микросервисы?

Многие компании, которые разрабатывают самые высоконагруженные приложения, с миллиардами запросов в секунду, используют монолиты и монорепы. Ярким примером является Facebook и Instagram. В бэкенде это монолиты. Конечно, у них есть большое число других компонент, которые вынесены в отдельные сервисы, но основной backend, который принимает и обрабатывает запросы от фронтенда (веба или мобильного приложения), содержит бизнес логику - это монолит.

Backend Facebook изначально был написан на PHP в 2004 году. Далее его плавно мигрировали на собственный язык hacklang и собственную виртуальную машину hhvm. При этом он остался, по большей части, колоссального размера монолитом.
Аналогично, Instagram написан на python (django). Основная часть все еще остается монолитом.

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

Более того, весь код этих приложений находится в монорепе и используется trunk-based development. Т.е. все изменения сразу делаются в основной ветке разработки.

Почему так? Какие это дает преимущества?

Монорепа:
1) Проблема версионирования API решается на уровне компилятора. Если вы меняете какое-то API, то вы не сможете запушить это изменение в trunk до тех пор, пока не измените все call site (все места, где это API вызывается). Вам не позволит компилятор, ваш код просто не скомпилируется. Если у вас множество репозиториев, то изменение API в одном месте не блокирует вас запушить это изменение. Вы создадите новую версию вашего API. Всем клиентам нужно про это узнать, и делать процесс миграции на новую версию. Нужно менять код, зависимости и т.д. Очень часто это приводит к багам в проде. Когда клиент ожидает одного поведения или семантики API, а в проде уже задеплоена другая версия.
2) Полностью решается проблема dependency hell. Проблемы зависимостей на разные версии одной и той же библиотеки со стороны разных зависимостей вашего модуля. Круговые зависимости и т.д. Тут все решается автоматически на уровне компилятора.
3) Легкий поиск по коду. У вас весь код под рукой. Если он проиндексирован можно легко найти любой интересующий вас код.

В Амазоне отдельные репы. Там целая наука работы с зависимостями. Есть свои тулы, концепции и т.д. Там есть тул brazil, понятие version set и много всего другого. Это постоянно приводит к затыкам с зависимостями, багам в проде из-за версионирования. Часто пуш сторонней библиотеки может заблокировать ваш CI/CD пайплайн, т.к. у вас поломались зависимости.

Монолиты:
1) Высокая производительность. В микросервисах вызов функции происходит по сети, что работает за миллисекунды. В монолитах вызов происходит в рамках одного процесса и работает за наносекунды.
2) Нет проблемы версионирования API в проде. Это решается на уровне компилятора. Это типичная проблема микросервисов.
3) Легко тестировать. Вы можете протестировать все e2e. В микросервисах часто очень сложно или не возможно протестировать приложение e2e. Вы можете протестировать свою компоненту, но не весь функционал в целом. Особенно, если у вас под 100 тысяч микросервисов, как в условном Amazon.

Trunk-based development:
1) Отсутствие Merge-Hell. Если вы разрабатываете крупную фичу в отдельной ветке, ее потом сложно мержить в trunk. Мелкие и частые изменения предотвращают тяжелые конфликты вмерживания.
2) Можно сделать реальный и быстрый CI/CD. В Мета любое изменение вмерживается, компилируется, тестируется и деплоится в прод за несколько часов. Не нужно делать долгие, сложные и редкие релизы.

Какие есть с этим проблемы и как их решили в Facebook/Instagram?
1) Производительность системы контроля версий. Если у вас очень много кода в одном репозитории как в Meta (миллионы файлов, десятки, если не сотни миллионов строк), то система контроля версий может на справиться по производительности. Поэтому Мета сделала свою систему контроля версий на основе Mercurial (git не справлялся с такими масштабами).
2) Feature Flags. Из-за trunk-based development у вас деплоится множество функционала в промежуточном состоянии. Для этого вам нужно иметь возможность ее включать и выключать в проде, проводить тестирование в проде и т.д. Для этого вам нужно активно использовать feature flags.
3) Привязка к одному языку программирования. Это неустранимая особенность. Приходится писать на том языке, на котором написан монолит.
4) Влияние проблем в одной фиче на другую/независимое масштабирование. Если одна функциональность стала работать плохо (потреблять много памяти, бросать ошибки, потреблять много процессорного времени и т.д.), то это может повлиять на работоспособность другого функционала, т.к. весь функционал живет на одном и том же сервере (т.к. это монолит). Это решено на уровне виртуальной машины/контейнера приложений. В Python у вас создается несколько отдельных процессов. Которые способны обрабатывать запросы независимо друг от друга. Число процессов зависит от числа ядер процессора. Процессы не шарят между собой память. Их можно независимо друг от друга мониторить, убивать и перезапускать. В hacklang и hhvm процесс один, но имеет множество потоков, которые имеют изолированную память, которую можно независимо друг от друга ограничивать. Потоки более легковесные, чем отдельные процессы. Но при этом они не шарят память между собой. В Java такое реализовать не получится. Там также один процесс и отдельные потоки на каждый запрос. Но потоки используют одну и туже память (Java Heap).
5) Проблемы с ownership кода. Из-за того, что весь код в одной большой куче, сложно разграничивать, кто отвечает за тот или иной код. В Meta эта проблема решена плохо. Тут есть и плюсы и минусы. С одной стороны, вы не ограничиваетесь кодом своей команды и можете при необходимости изменить любой код. Но важно, чтобы те, кто отвечает за этот код как минимум, проревьюили это изменение. В Meta с этой целью к каждому файлу добавляется специальная аннотация/тег - какая команда владеет этим кодом. И при его изменении, автоматически в код ревью добавляются люди из нужной команды.
6) Сложно засетапить CI/CD. Нужно, чтобы компиляция на такой большой базе кода работала быстро, а также тесты прогонялись быстро. Для этого вычисляется дельта, и прогоняется только подмножество тестов, на которые может повлиять ваше изменение.