FAANG Master

Новая презентация про изменения продуктивности программистов благодаря AI

Это снова презентация от той же группы исследователей из Стэнфорда. Результаты исследований презентовал Yegor Denisov-Blanch.

Пост про его предыдущую презентацию тут: Еще одно исследование улучшения продуктивности программистов при помощи AI

Сама новая презентация: https://www.youtube.com/watch?v=JvosMkuNxF8

Основные результаты:

1) Внедрение AI увеличивает продуктивность программистов и это увеличение продуктивности растет со временем. Если в 2023 увеличение продуктивности от внедрения AI было около 0. В 2024 среднее изменение продуктивности от внедрения стало уже 5%, а в 2025 - около 10%.
2) Продуктивность от внедрения AI слабо коррелирует с числом используемых токенов. Т.е. важно не количество используемых токенов, а качество того, как вы используете AI.
3) Увеличение продуктивности от внедрения AI сильно зависит от изначального качества кода. Clean Code позволяет получить большее увеличение продуктивности от использования AI. (Мой комментарий: Но вообще, это скорее связано с его предыдущим результатом про маленькие репозитории, т.к. они в индексе качества кода использовали в том числе размер репозитория.)
4) Одинаковый доступ к AI тулам не означает одинаковое использование AI разными командами. Многие компании внедрили AI для повышения продуктивности программистов, но тем не менее разные команды используют AI в разной степени, хотя доступ к тулам одинаковый.
5) Число Code Review/PR увеличилось сильно, но увеличилось число Code Review/PR на Rework. Т.е. программисты пушат больше кода и сильно больше потом переделывают. Поэтому число PR может увеличиться на 40%, но 20%-30% - переделывание предыдущих PR сгенерированных при помощи AI. Поэтому на 2025 год среднее увеличение продуктивности находится на уровне 10%.
6) Качество кода уменьшилось от внедрения AI. Не смотря на увеличение продуктивности, качество кода уменьшилось на 9%.

Основные результаты из предыдущей презентации:

1) Нет корреляции между тем, как программисты сами оценивали изменение своей продуктивности и тем как продуктивность изменилась в реальности. Т.е. нельзя использовать опросники программистов про влияние AI на свою продуктивность. Нужно делать реальные замеры и не опираться на опросы.
2) Продуктивность менялась от уменьшения продуктивности на десятки процентов до увеличения продуктивности на 40% в зависимости от условий, типов задач, сложности задачи и языка программирования.
3) В задачах, на которых продуктивность увеличилась на 40%, половину пришлось переделывать. Т.е. увеличилась продуктивность, но и потребовалось существенную часть переделывать. Это как два шага вперед и один шаг назад. В реальности продуктивность на этих задачах выросла на 15%-20%.
4) Продуктивность выросла на следующих типах задач: простые задачи, популярные языки программирования (python, js), маленькие базы кода.
5) Продуктивность выросла меньше или уменьшилась на следующих типах задач: сложные задачи, редкие языки программирования или большие базы кода.

Какую документацию имеет смысл писать?

Смотри пост про комментарии в коде: Комментарии в коде

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

Но что имеет смысл все таки документировать?

Обычно это делается во внутренней вики компании (Например, Confluence).

1) Цели команды, какие задачи (бизнес или не бизнес) она решает. Чтобы вас можно было легко найти по тексту проблемы, которую хочет решить другая команда. И зайдя на страницу вашей команды, сразу стало понятно, чем вы можете быть полезными кому-то еще.
2) Описание основного функционала, который может быть полезен другим командам или вне компании. Это описание фич, которые предоставляет ваша команда.
3) Customer onboarding. Если кто-то захочет использовать ваш функционал, как ему заонбордиться? нужно ли создать какой-то onboarding тикет, или просто начать использовать какое-то публичное API. Нужно подробно описать все шаги, как кастомеру стать вашим клиентом.
4) Public API. Детальное описание API, которое вы предоставляете внешним клиентам (внутри или вне компании).
5) SLOs, SLAs, SLIs. Если есть и применимо к вашему функционалу.
6) Support and Monitoring for Customers. Как ваши клиенты могут трекать состояние вашего сервиса? какие метрики или дашборды они могут использовать? Как связаться с саппортом если у них проблемы? Как поднять тикет, запейджить, написать кому-то и т.д.
7) Описание Архитектуры вашего решения. Не комментарии к коду i++, а диаграммы с описанием высокоуровневой архитектуры и архитектуры тех или иных фич.
8) Internal Support and Monitoring. Детальные метрики, алармы, дашборды, ранбуки для саппорта, которыми будет пользоваться тот, кто саппортит вашу функциональность.
9) Онбординг для новичка вашей команды. Документы, которые нужно прочитать человеку, который только пришел работать в вашу команду. Где найти код, как настроить среду разработки, как тестировать, запускать, деплоить и т.д. Как устроен процесс разработки, релиза и все что потребуется человеку для работы в вашей команде.
10) User Manual, FAQ. Детальное описание того, как пользоваться вашим функционалом со стороны клиента. Описание типичных проблем и их решения. Типичные уточняющие вопросы и ответы на них.
11) Внутренние дизайн доки. Когда вы дизайните новую фичу, компоненту и т.д. вы пишете дизайн док/RFC. Он проходит дизайн ревью и ложится в основу реализации фичи. Имеет смысл этот док сохранить для понимания причин того или иного решения + атачить ссылку на этот документ в code-review и коммитах. Чтобы в системе контроля версий видеть, почему что-то было сделано так и не иначе.
12) Code-style. Если вы создали и договорились про какие-то стили в кодирование, то можно это зафиксировать в виде документа. Это может быть список Code Smells.
13) Team and org chart. Кто менеджер, тим-лид, список всех членов вашей команды. С тем можно поговорить потенциальному клиенту. Как ваша команда вписывается в структуру компании? в каком орге она находится и т.д.

Рекомендую сериал Devs

Если еще не смотрели, рекомендую сериал Devs (Программисты/Разрабы).

Другие фильмы, документалки и сериалы про программистов, основателях компаний смотрите тут:
Подборка фильмов, сериалов и документалок о программистах, BigTech, стартапах и их основателях

Если искали, что бы послушать в выходные, не ищите дальше

Официальный саундтрек чемпионата мира по Microsoft Excel: https://youtu.be/xJL573PGYak

Мета сокращает расходы на метаверс на 30%.

Последует ли очередная волна сокращений?

На Метаверс были потрачены огромные деньги (50+ миллиардов долларов). Даже переименовали компанию из Facebook в Meta. Результат на картинке.

Mark Chen на подкасте у Ashlee Vance рассказал, что Марк Цукерберг пытался рекрутировать половину его подчиненных.
Он не только предлагал десятки и сотни миллионов долларов за переход, но и сам приготовил суп и сам его приносил домой потенциальным новым сотрудникам.
Mark Chen - Chief Research Officer в Open AI.
Его линкедин: Mark Chen
Он также является главным тренером сборной США на международной олимпиаде по информатике.

Представьте, вы просыпаетесь от звонка в дверь, а там Цукерберг с супом.

Подкаст: https://www.youtube.com/watch?v=ZeyHBM2Y5_4

Laurent Simons получил PhD по квантовой физике в возрасте 15 лет

PhD - это аналог кандидатской диссертации.
В возрасте 8 лет он закончил школу, в 10 лет получил бакалавра, в 12 - магистра. И наконец в 15 защитил PhD.
Дальше планирует переключиться с квантовой физики на медицину и AI. У него IQ - 145.

Это вам не жаловаться на незнание того, как работает хеш-таблица и как инвертировать дерево.

Новость

Чего мне больше всего не хватает, спустя 5 лет жизни в Лондоне?

Недавно исполнилось ровно 5 лет с тех пор, как я переехал в Лондон.

Чего мне больше всего не хватает в Лондоне, по сравнению с жизнью в Москве?
Это березки? Водка? Доставка за 10 минут? - Нет.

1) Сложно встретиться с родственниками. Живя в Москве, я мог относительно просто приехать к родственникам. Живя в Лондоне это затруднительно. Особенно в последние 5 лет.
2) Еда в кафе и ресторанах. Я бы не сказал, что в Лондоне она хуже, просто она другая. Вкусы и предпочтения в еде мало изменяются за жизнь.
3) Столовые. У нас есть столовая в офисе. Но столовых по городу нет или практически нет. Это снгшная тема. Тут только кафе и рестораны. Поесть борщ, пюрешку с котлеткой, гречку и две соски, компот можно только в русском ресторане или в доставке.
4) Фильмы и шоу на русском. В кинотеатрах фильмы только в оригинале на английском. Это, конечно, полезно, но приходится дополнительно напрягать свой мозг. Особенно, если у актера британский акцент. Про театры и постановки Шекспира я молчу, там происходящее понятно только из действий.
5) Покрытие мобильного интернета. Тут в метро практически нет интернета. Более того, даже на улице не везде ловит мобильный интернет.
6) Платные больницы и инвитро. Платные больницы и больницы по платной страховке тут есть, но экспириенс от них все же другой. Все более сложно устроено и сильно дороже. А прямого аналога инвитро нет. Есть разные аналоги, с разным набором услуг. Но большой, дешевой, во всеми возможными анализами и удобной сети нет.


Смотри также:
1) Бытовые особенности жизни в Лондоне. Часть 1.
2) Бытовые особенности жизни в Лондоне. Часть 2.
3) Бытовые особенности жизни в Лондоне. Часть 3.

Вышло интервью в соавтором статьи Attention Is All You Need

Интервью с Ильей Полосухиным.
Он является соавтором статьи Attention Is All You Need, в которой описана архитектура трансформера(по сути - создание LLM). OpenAI, используя эту архитектуру, обучила её на данных всего интернета, что привело к созданию ChatGPT.

Сам Илья, сейчас занимается другими вещами. Он переключился на блокчейн.

Его линкелин: Illia Polosukhin

Само интервью: https://youtu.be/k17HfILvMnA

Таймкод про историю изобретения трансформера — 1:28:00

Начиная с февраля 2026 сотрудники Инстаграмма должны ходить в офис 5 дней в неделю

На данный момент RTO(return-to-office) policy обязует ходить в офис 3 дня в неделю. Это приводит к так называемому Coffee Badging, когда люди приходят в офис на несколько часов для галочки.
Начиная с февраля сотрудники в США, которые работают над Instagram, должны будут ходить в офис 5 дней в неделю.

Amazon вернул 5-дневную рабочую неделю еще в январе 2025 года.

В какую из FAANG-компаний самое сложное Coding-interview?

Краткий ответ: Google.

Несмотря на то, что в Google на решение задач дают больше времени — нередко это одна задача на 45 минут или задача + follow-up — сами задачи, как правило, сложнее, чем в других компаниях. Google любит спрашивать динамическое программирование и задачи на графы. Кроме того, это часто уровень LeetCode Hard.
Остальные этапы собеседования в Google не самые сложные по сравнению с другими FAANG-компаниями. Поведенческое собеседование (на googliness) проще, чем во многих других компаниях (в том же Amazon, например). А System Design примерно на том же уровне, что и в Meta.
В Meta на coding-интервью всегда дают по две задачи, и у вас есть по 20 минут на каждую. Но большинство задач уровня Medium, а динамическое программирование, как правило, не спрашивают. Более того, субъективно, вариативность задач ниже, поэтому, выучив наизусть первые 30 самых частых задач, с большой вероятностью вы получите на собеседовании хотя бы половину именно из этого списка.

Комментарии в коде

Don't comment bad code - rewrite it.
Brian W. Kernighan and P. J. Plaugher

Эта цитата из начала главы 4: Comments из книги Clean Code (Robert C.Martin)

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

Значит ли это, что комментарии в коде писать не надо вообще?

Нет. Комментарии в некоторый случаях полезны:

1) Хорошее описание public API. Если вы разрабатываете библиотеку, которая используется другими командами внутри вашей компании или вне ее. Или API/Endpoint, которое вызывают другие команды. Если это Java - можно писать Javadocs. Но описание API должно быть хорошим и полезным. Писать комментарии в стиле капитан очевидность смысле не имеет. Часто приходилось видеть Javadocs:

/**
 * Processes user order.
 *
 * @param userId the user id
 * @param products the products
 * @param applyDiscount the apply discount
 * @param sendEmail the send email
 */
public void processUserOrder(long userId, List<Product> products,
                             boolean applyDiscount, boolean sendEmail) {
    // ...
}

```
В таком Javadocs смысла не очень много.
2) Описание причин, почему так сделано. Если код выглядит плохо и очень хочется его переписать, но вы уже пытались и по каким-то причинам были вынуждены остановиться на воркэраунде, имеет смысл в комментарии объяснить, почему сделано именно так, а не иначе.
3) Предостережения. Похоже на предыдущий вариант, но если вы знаете, что изменения в этом коде в ту или иную сторону или его использование в определенном контексте приведет к очень плохим последствиям - стоит написать комментарий.
4) Пояснения, которые сложно выразить в коде. Иногда код невозможно сделать более читаемым из-за особенностей языка программирования, и он всё равно остаётся не очень удобным для восприятия. В таких случаях можно оставить информационный комментарий.
5) TODO. Имеет смысл оставлять такие комментарии о том, что планируете изменить, дописать, улучшить в будущем.
6) Копирайты, если это требует ваша компания. Иногда компании по дефолту заставляют в каждый файл добавлять комментарий вверху или внизу с копирайтом, лицензией и т.д.

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

Например:
1) Комментарии в стиле капитан очевидность.

//Increment i
i++;

/** The name */
private String name;

2) Комментарии, которые можно убрать переименовав функцию, переменную или аргумент.

// timeout in milliseconds
long TIMEOUT = 5000;

Лучше:

long TIMEOUT_IN_MILLISECONDS = 5000;

//Extract user name from the input string
public String parse(String str) {
...

Лучше:

public String extractUserName(String commandLineParameters) {
...

3) Комментарии, когда можно вынесли логику в отдельную функцию.

// Проверяем, можно ли показать пользователю промо-баннер
if (user != null
        && user.isLoggedIn()
        && !user.isPremium()
        && featureFlags.isPromoBannerEnabled()) {

    showPromoBanner(user);
}

Лучше:

if (shouldShowPromoBanner(user)) {
    showPromoBanner(user);
}

private boolean shouldShowPromoBanner(User user) {
    return user != null
            && user.isLoggedIn()
            && !user.isPremium()
            && featureFlags.isPromoBannerEnabled();
}

4) Закомментированный старый код. Просто удаляйте код. Сейчас уже давно существует система контроля версий, которая хранит всю историю.
5) Комментарии (Javadocs) для не публичного API. Писать Javadocs ради самого факта их наличия не нужно. Не стоит писать комментарии для API, которое никем, кроме вас и вашей команды, не используется.

Предотвращают ли тесты баги в проде?

Краткий ответ: нет.

Даже со 100% покрытием кода тестами мы не можем гарантировать, что багов в проде не будет. Тесты лишь фиксируют текущее понимание разработчиком того, как код должен и может работать. Если это понимание не верно, то тесты не предотвратят баги. Более того, источником багов часто становятся различные конфигурационные изменения (конфигурация сети, базы, изменение бизнес правил и настроек), изменения в API зависимостей, которые вы используете, очень редкие race conditions и т.д.

Если тесты не предотвращают все баги, то и нет смысла их вообще писать?

Тесты писать смысл есть, в том числе и для предотвращения багов.

Польза тестов:

1) Проверяют, что код работает так, как ты ожидаешь (хоть это ожидание может быть и не верным). Позволяет убедиться, что написанный код как-то работает и предотвращает кучу глупых багов.
2) Документирует код. Тесты - это лучшая документация к коду, которую можно придумать. Она актуальна. Т.к. если код изменился, то тесты перестанут работать. Так же разработчику проще понять как передать параметры, как вызвать этот код, как распарсить результат на примерах, чем прочитав сотни слов об этом. В Amazon часто приходилось интегрироваться с другими компонентами, и проще всего это было сделать — посмотреть интеграционные/e2e тесты, скопировать код теста к себе и поменять вызов и парсинг результата под свои нужды.
3) Можно спокойно делать рефакторинг кода. Если у вас хорошее покрытие тестами, то если при рефакторинге у вас начинают падать тесты, значит вы что-то сломали, или вам надо поправить сигнатуры вызовов в тестах. Вы можете с большой уверенностью гарантировать, что вы ничего своим рефакторингом не сломали. Если у вас нет хорошего покрытия тестами, то делать рефакторинг опасно.
4) Предотвращает регрессию. Вы делаете новое изменение в коде, добавляете тест и он работает. Но при этом этот код может поламать другой функционал и без хорошего покрытия вы об этом не узнаете.
5) Проверка, насколько удобен ваш код для клиента. Во время написания теста можно понять насколько просто или сложно ваш код использовать. Если тест писать сложно, то и использовать ваш код будет не просто.

Хоть тесты и хорошее покрытие не предотвращают все баги в проде, они имеют много другой пользы. В Amazon, в нашей организации покрытие тестами было 95-97%. Тем не менее, баги и аутэджи случались. Но чаще они были связаны с конфигурациями, версиями API, неправильным пониманием бизнес-логики или очень редкими стечениями многих факторов, которые трудно воспроизвести в тесте.

Ещё одно наблюдение из моего 18-летнего опыта: на количество багов в проде больше влияет не процент покрытия тестами, а качество разработчиков. В Meta покрытие тестами сильно меньше, но число багов очень маленькое.

Предыдущие части:
1) Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 1.
2) Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 2.

Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 3.

AI Bubble

Появляется все больше свидетельств того, что AI создает финансовый пузырь. При этом это не значит, что LLM и текущие генеративные модели не работают или бесполезны. Даже в текущем виде они полезны. Люди перестают искать информацию напрямую в поисковиках, в ней копаться и находить ответы. Сейчас эту функцию на себя берут LLM. Т.е. ChatGPT является прямым конкурентом поиску Google. Поэтому для Google стать лидером в AI является вопросом выживания. И на данный момент похоже на то, что Google начинает эту гонку выигрывать. Релиз Gemini 3 превзошел все ожидания и сместил ChatGPT с лидерских позиций. Более того, у Google есть давно и хорошо работающая монетизация через рекламу. Чего нельзя сказать про Open AI. У них пока все также нет нормальной монетизации, а подход с платными подписками пока работает в убыток.
Несмотря на полезность LLM в качестве замены/эволюции поиска - объемы инвестиций непропорциональны. Инвестиции измеряются триллионами долларов. Как будто LLM не сегодня-завтра заменит всех людей, решит все проблемы энергетики, найдет лекарство от рака и людям можно будет не работать и получать базовый доход. Но пока это не звучит реалистично.
Более того, все очень похоже на ситуацию с пузырем доткомов. Тогда кидали большие деньги во все компании, у которых появлялся сайт .com. При этом никакой работающей бизнес модели не было. Сейчас достаточно добавить AI в название своей компании и можно получить астрономические инвестиции. Сейчас люди получают 2 миллиарда долларов инвестиций без бизнес модели, просто имея слоган и 1-страничный сайт. Крупные игроки инвестируют сотни миллиардов долларов в строительство датацентров. При этом, стоимость видео карт для этих датацентров составляет существенную часть. Недавно Майкл Бьюри (это прототип главного героя фильма Игра на понижение, который заработал 700 миллионов для своих клиентов и 100 миллионов долларов для себя лично на кризисе 2008) зашортил Nvidia. Он посмотрел финансовые документы крупных компаний, и показал, что они завышают время использования видеокарт для своих будущих датацентров. Если раньше они закладывали, что видеокарты нужно менять раз в 3-4 года, то сейчас 6-7 лет. Это делается для искусственного занижения будущей стоимости работы этих датацентров. Варианты и число спекуляций для роста цен на акции продолжает расти: круговые сделки, массовые сокращения для перенаправления в AI, найм разрабов за сотни миллионов и миллиарды долларов. Даже сам Сэм Альтман, Сундар Пичаи, Марк Цукерберг, Безос и другие говорят про AI Bubble.

Риски в ближайшие годы

Перенаправление ресурсов в AI и возможный коллапс AI пузыря может привести к новым большим волнам массовых сокращений. Более того, за последние 5 лет IT индустрия создала много новых программистов. Сначала из-за роста использования онлайн ресурсов в ковид, а теперь для работы над AI. Кроме того, одной из коренных причин массовых сокращений в 2022-2023 годах стало отсутствие новых точек роста. Предыдущие проблемы масштабирования уже решены (поиск, соц сети, реклама, мессенджеры, видео контент). А новые не создали большое число новых рабочих мест (блокчейн, IoT, AR/VR). Все это создает предпосылки для очень конкурентного рынка программистов. Когда на рынке труда будет переизбыток программистов и недостаток вакансий. Кроме того, рост производительности программистов на 5%-20% из-за AI и ожидание, что AI скоро всех заменит может еще сильнее усугубить ситуацию для программистов в краткосроке, особенно для Junior программистов.

Возможные позитивные сценарии для программистов в среднесрочной перспективе

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

Вышло новое интервью с Ильей Суцкевером

Это сооснователь Open AI, ученик Джефри Хинтона(крестный отец Deep Learning, лауреат Нобелевской премии 2024 года по физике, благодаря нему появился метод обратного распространения ошибки в нейросетях).
Сейчас он ушел из Open AI и делает свой стартап.

https://youtu.be/aR20FWCCjAs

Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 2.

Агентность и замена джунов
Не смотря на появление MCP и аналогов, AI все еще не хватает агентности. Ты не можешь сформулировать задачу для AI в 5 предложений и ожидать сделанную задачу на уровне мидла/синьера с таким же уровнем самостоятельности. AI все еще требует кучу бебиситинга и хендхолдинга. Это джун в лучшем случае. Но заменить джунов в долгосроке не получится. Джун это просто стадия роста программиста. Придется заменять всех (как минимум до Senior включительно). Иначе откуда брать Senior в долгосроке, если уволить всех джунов? Более того, AI не обучается на работе. Когда новый сотрудник приходит (даже Senior) ему требуется время для разгона (6 месяцев). Но он при этом обучается всем особенностям компании, отдела и команды. Ему не надо будет объяснять одни и теже вещи много раз. Он получает и кеширует контекст. Для AI каждый запрос как с чистого листа. Как будто он никогда не решал задачи для вашей команды или компании до этого.

Прогресс или его отсутствие в развитии AI
Под AI я имею ввиду генеративные модели. ML используется и приносит тонну пользы и триллионы долларов в год уже давно. Я говорю про текущий хайп генеративных моделей.
Прорыв случился в 2017 году с созданием трансформеров: Attention Is All You Need. Open AI смогла обучить LLM на данных со всего интернета, что и привело к созданию ChatGPT и текущему хайпу. С тех пор прогресс не существенный. Появился встроенный поиск (RAG), Chain-of-Thoughts (что просто вариант промт инжиниринга), обучение модели дополнилось тысячами ручных лейблеров при помощи Reinforcement learning from human feedback. Качественные данные для обучения заканчиваются, новых архитектур нет, и все изменения инкрементальные. Прогресс замедлился и экспоненциальных скачков не предвидится. Есть идеи про World Models (одним из вариантов занимается Ян Лекун), но это пока на уровне исследований.

Продолжение следует.

Что там по замене программистов при помощи AI через 3 года после релиза ChatGPT? Часть 1.

Прогнозы

Прошло практически 3 года с момента релиза ChatGPT в ноябре 2022 года. С тех пор не утихают разговоры про замену программистов (и не только) при помощи AI в ближайшем будущем.
В этом году CEO Anthropic (Claude) делал прогноз, что до конца лета AI заменит 90% программистов, а до конца года уже всех.
Марк Цукерберг в начале года делал прогноз, что до конца 2025 AI будет на уровне мидла в Мета.
Пока не похоже, что эти прогнозы сбываются.
Сэм Альтман откладывал релиз ChatGPT 5.0, т.к. он уже 3 года всех кормит наступлением AGI и все ждали, что пятая версия будет уже этим AGI. Прогресс с предыдущего поколения моделей есть, но не существенный. Нет качественного изменения.

Продуктивность и исследования

Есть исследования, которые показывают, что буст продуктивности есть, но только на определенных типах задач:
1) Популярные языки
2) Маленькие репозитории
3) Простые задачи

Что подходит для демо, прототипирования, пет-проектов, маленьких компаний на ранних стадиях. Тут буст продуктивности может быть очень существенный.
Более того, число изменений кода может расти вплоть до 40%, но 20% из них приходится переделывать. При этом средний буст продуктивности лежит в диапазоне 5%-10%.

Исследования:
1) Повышает ли AI производительность программистов?
2) Еще одно исследование улучшения продуктивности программистов при помощи AI

Массовые сокращения
Массовые сокращения в IT не связанны с заменой программистов. В 2022 и 2023 - оверхайринг в ковид и наступление постковида, спрос на IT-продукты перестал расти экспоненциально как в ковид. в 2024, 2025 - хайп вокруг AI, страх компаний проиграть в AI гонке и стать новым Yahoo или Kodak. Поэтому все крупные игроки перенаправляются ресурсы в разработку AI.

Тул для личной продуктивности и проблемы

При этом AI по большей части остается ассистентом и тулом для личной продуктивности. Его внедрения в продукты компаний не приносит денег, а только убытки. Есть исследования, что только 5% компаний внедрила AI в свои продукты, при этом 40% компаний пытались. Существенно больше компаний внедрило AI в качестве ассистентов для своих сотрудников с сомнительным ростом продуктивности и затратами на эти тулы.
На данный момент это остается следующей ступенью развития google+stackoverflow+github+автокомплитеры, которые, как по мне, принесли не меньший буст продуктивности в свое время. Просто это было растянуто на много лет. Все эти демо - сгенерируй змейку или тетрис впечатляют, но такой же код можно найти в пет-проектах на гитхабе. Это займет сильно больше времени, но результат будет тот же. Кроме того, после первоначальной генерации, очень сложно модифицировать код под свои нужды.
Аналогичной проблемой страдают всяческие генераторы видео и музыки. Они не позволяют точечно редактировать и добиваться того, что вам нужно. Кто пытался генерировать мемы при помощи последних моделей вроде veo 3, sora 2, nano banana и т.д. это вопрос удачи. Вы генерируете что-то в надежде, что будет то, что вы хотите. Если не получилось, он не редактирует немного - он геренит заново. Поэтому по факту это не тул, а игра в лотерею. Ты генерируешь десятки и сотни вариантов и из них выбираешь. Аналогично с кодом, вайб кодинг не работает. Первоначальная генерация быстрая, но разобраться в коде, кастомизировать, устранить баги из-за галлюцинаций - все это требует времени и усилий.

Какая у вас статистика прохождения System Design и алгосов?

На данный момент у меня такая:
1) Собеседования по алгоритмам - 56% раундов пройдено успешно за всю карьеру
2) Собеседования по алгоритмам в FAANG - 78% раундов пройдено успешно
3) System Design - 100% успешно пройденых раундов

Статистику по алгосам я подпортил за 2011-2015 годы, когда ничего про подготовку не знал и не готовился. За эти годы у меня только 20% успешных прохождений.