Alexander Wang: если интеллект перестаёт быть дефицитом (Рубрика #AI)

Посмотрел разговор Гарри Тана с Александром Ваном на Startup School 2026 "Alexandr Wang: “This is a Once-in-a-Civilization Opportunity", опубликованный 29 июля 2026 года. Ван основал Scale AI, а сейчас занимает позицию Chief AI Officer в Meta, запрещенной в России. Но интереснее должностей его главный прогноз: интеллект и способность действовать станут изобильными, а дефицитом останутся видение, амбиция и умение собирать систему вокруг агентов.

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

Отсюда его версия персонального сверхинтеллекта (personal superintelligence): миллиарды людей получают персональных агентов, а миллионы компаний - агентов, которые договариваются между собой. Разработчик в этой картине поднимается по уровням абстракции: сначала писал код, затем оркестрировал отдельных агентов, дальше будет проектировать организации из миллионов или даже триллионов агентов. Но это пока футуристический прогноз, хотя основной механизм Ван описывает вполне приземлённо. Нужен замкнутый контур: цель, данные, действие, обратная связь и метрика, по которой система понимает, стало ли лучше. По его утверждению, внутри Meta удачный агентный контур (agentic loop) с подходящей проверкой качества (eval) уже позволял рою агентов делать больше команды из ста инженеров, но публичных данных для проверки этого сравнения в разговоре нет. Интересно, что концепцию Loop Engineering мы разбирали недавно с Максом Смирновым.

После просмотра видео с Alexander Wong я вспомнил, что Джефф Дин, о выступлении которого на Y Combinator School 2026 я рассказывал вчера, около десяти лет назад приходил говорить про будущее (это было на YC AI от 7 августа 2017 года). Дин тогда показывал TensorFlow, TPU, neural architecture search и формулировал «запросы будущего»: описать видео на испанском; найти работы по reinforcement learning для робототехники и суммировать их на немецком; научить робота безопасно работать рядом с людьми в неструктурированной среде. Первые два сценария сегодня уже не звучат как научная фантастика. Третий всё ещё остаётся фронтиром: модели научились лучше понимать сцену и инструкции, но надёжное физическое действие и безопасность требуют отдельного инженерного контура.

Разница оптик показательна. Дин смотрел на модель как на новый вычислительный инструмент и спрашивал, какие задачи она сможет решить. Ван начинает с предположения, что цифровой интеллект уже стал дешёвым и доступным, и спрашивает, кто поставит ему цель и соберёт из него работающую организацию. Единица изменения выросла от модели и запроса до компании и её контуров обратной связи. Но есть и важное сходство. Ни один не предсказывает исчезновение инженерии. У Дина человеческая экспертиза переезжала в архитектуру данных, вычислений и автоматизацию экспериментов. У Вана она переезжает в постановку целей, оркестрацию, evals и системное мышление. Абстракция меняется, а ответственность за устройство системы остаётся.

И здесь я бы не принимал весь оптимизм Вана за нейтральный прогноз. Разговор одновременно продвигает стратегию Meta, Muse Spark и будущую платформу для агентов. Оценки «в десять раз», «в сто раз» и сравнение со ста инженерами - позиции спикера, а не независимые бенчмарки.

#AI #Agents #Engineering #Architecture #Leadership #Management

Материалы по прямому эфиру с Евгением Сергеевым про то, как строить работающие evals (Рубрика #AI)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Евгением Сергеевым:
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software #Architecture #Evals

Через 5 минут стартует прямой эфир Code of Leadership с Артемом Бондарем про GenAI вне разработкки:)
Приходите и задавайте вопросы, мы с Артемом с удовольствием на них ответим.

Research Insights Made Simple #27: AI-разработка как эволюционирующий стек (Рубрика #AI4SDLC)

Почему одна и та же модель в двух кодинговых агентах даёт настолько разный результат? И что компании действительно стоит считать своим AI-стеком: модель, обвязку, инструменты, данные или право агента менять внутренние системы?

В пятницу, 7 августа, в 27-м выпуске "Research Insights Made Simple" в прямом эфире разберу AI-разработку как совместно эволюционирующую производственную систему. В этот раз без гостя: хочу собрать в одну картину выводы из последних исследований и инженерных разборов — от hardware-software co-design до agent harness, MCP, evals и production traces.

Главная идея выпуска: преимущество всё реже живёт в одном компоненте. Сильная модель становится продуктом только внутри конкретной среды - с контекстом, примитивами действий, identity, policy и доказательствами результата. А сбой превращается в улучшение, только если команда умеет воспроизвести его, изменить нужный слой и заново пройти проверку.

Поговорим о том:

- Почему не каждый сбой требует новой модели и чем быстрый цикл настройки tools и harness отличается от медленного цикла model и hardware;
- Почему API-совместимость и MCP ещё не дают поведенческой совместимости, корректных полномочий и безопасного эффекта;
- Чем telemetry отличается от evals и training data — и почему production traces не улучшают модель автоматически;
- Где провести границу между арендой, адаптацией и созданием своего: что разумно арендовать у провайдера, что адаптировать, а чем компания должна владеть сама;
- Когда собственная обвязка действительно оправдана, а когда она превращается в дорогую попытку повторить общий агентный цикл.

Для меня главный вывод такой: возможности компании не в модели и не количество MCP-серверов, а скорость доказанного изменения. Увидеть реальный сбой, сохранить эпизод, воспроизвести его, поправить один слой, пройти release gate и безопасно вернуть улучшение в production.

#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals #Engineering

Гарри Тан про AI-native компанию: память важнее модели (Рубрика #AI4SDLC)

Посмотрел доклад Гарри Тана, президента и CEO Y Combinator, «Every company should have a Brain» с AI Engineer World’s Fair 2026. Главный тезис: преимущество даёт не особая модель, а организация работы вокруг агентов и накопленного контекста. По собственной оценке Тана, его производительность в программировании выросла до 400 раз, а со строгими поправками — в 8–80 раз. Это не benchmark, а личная оценка. Важнее другое: условные «2x» и «100x» разработчики используют те же модели. Разница - в обвязке.

Тан предлагает смотреть на агентную систему как на организацию:
- Skill-файл - сотрудник с одной обязанностью;
- Resolver - оргструктура, направляющая задачу;
- Правила хранения - внутренние процессы;
- Evals - проверка их работы (аля performance review)

Неоднозначные задачи Тан предлагает отдавать модели и сейчас это это понять намерение и сделать выбор. А состояние, расчёты, ограничения и проверки можно поручить детерминированному коду. Многие сбои начинаются там, где одно пытаются заменить другим. Но даже хороший агент ограничен контекстным окном, а компания - это библиотека из переписки, встреч, решений и postmortem. Поэтому «мозг компании» у Тана - не просто поиск, а библиотека плюс библиотекарь, выбирающий нужный контекст для задачи.

Свой вариант Тан развивает в открытом проекте GBrain - слое памяти и поиска для агентов с синтезом ответов, ссылками на источники и графом связей: Без источников, проверки противоречий и удаления устаревшего знания такой «мозг» превратится в свалку с хорошим поиском. Память здесь - production-инфраструктура, а не папка для всего подряд.

Практический совет от Гарри - не делать одноразовую работу. Удачный результат нужно превратить в повторяемый skill и проверить через eval. Тогда организация накапливает способность, а не каждое утро начинает с амнезии.

#AI #AI4SDLC #Agents #Engineering #Architecture #Management

Материалы по прямому эфиру с Артемом Бондарем про то, как внедрять AI в операционную работу (Рубрика #AI)

Готовы материалы с прямого эфира подкаста Code of Leadership с Артемом (@artemonml):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software #Architecture

Приходите мы с Лешей Литвиновым стартанули прямой эфир про AI в разработке

Джефф Дин покидает Google после 27 лет работы (Рубрика #Legend)

Буквально пару-тройку дней назад я рассказывал про лекцию Джеффа для стартаперов из Y Combinator. Ближе к концу там была такая фраза

Наконец, Дин ожидает, что в 2027 году заметно вырастет автоматизация самого ML: система будет раскладывать задачу, запускать множество экспериментов, оценивать результаты и собирать улучшенную версию. AlphaEvolve уже показывает форму такого цикла.

А сегодня появляется эта новость, где Джефф и его друзья стартуют лабу "Discovery Loop!" в формате

Public Benefit Corporation whose mission is to automate machine learning, science, and engineering to accelerate discoveries and progress

Теперь понятно за счет чего вырастет эта автоматизация:)
Ну а если серьезно, то с большим интересом буду следить за анонсами из этой новой корпорации, которую как объявил Сундар Пичай поддержит Google

#AI #Agents #Engineering #Architecture #Infrastructure #Product

Таненбаум, PagedAttention и фундамент, который не устаревает (Рубрика #Books)

Разбирался с интересным paper "Efficient Memory Management for Large Language Model Serving with PagedAttention" от создателей vLLM. В 2023 году авторы посмотрели, как современные на тот момент движки инференса LLM работают с памятью, и нашли почти криминальную по нынешним временам картину (убийцей эффективности был KV-cache).

Системы заранее резервировали под запрос непрерывный участок памяти исходя из максимально возможной длины последовательности. Но реальные ответы обычно короче, запросы растут динамически, память фрагментируется. По измерениям авторов, полезными данными было занято лишь 20,4–38,2% памяти KV-cache.

Авторы предложили PagedAttention: разделить KV-cache на логические блоки и отображать их на физические блоки памяти, которые не обязаны лежать подряд и выделяются по мере необходимости. По сути, они перенесли в LLM serving давно знакомые операционным системам идеи виртуальной памяти и страничной организации.

И тут я вспомнил, как с большим интересом читал "Современные операционные системы" Эндрю Таненбаума и Херберта Боса. Это был примерно 2017 год. Я уже год работал техническим менеджером в Тинькофф, но очень не хотел терять технические компетенции. Поэтому по выходным приезжал в офис: сначала позаниматься в фитнесе, потом - поботать технические темы. Одной из таких тем и стали операционные системы.

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

Книга последовательно разбирает:
- Процессы и потоки, планирование, межпроцессное взаимодействие и синхронизацию;
- Адресные пространства, виртуальную память, страничную организацию и алгоритмы замещения страниц;
- Файловые системы, хранение данных и ввод-вывод;
- Взаимоблокировки и способы их предотвращать, обнаруживать или переживать;
- Виртуализацию и облака, многопроцессорные системы и безопасность;
- Устройство UNIX, Linux, Android и Windows 8.1 как реальные примеры этих принципов.

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

Конечно, четвёртое издание - уже капсула времени. Windows 8.1 давно не современная система, а конкретные детали Linux, Android, безопасности и железа нужно дополнять актуальной документацией. И это точно не быстрый практикум по администрированию Linux. Но фундаментальные главы про процессы, память, файловые системы, конкуренцию за ресурсы и виртуализацию стареют гораздо медленнее конкретных API.

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

#Books #Engineering #Software #Architecture #OS #AI #DistributedSystems

Приходите мы стартуем прямой эфир, где Иван Гель расскажет про продукт UpCore, цифрового тимлида, а я буду задавать интересные вопросы

В плане обсудить:
- Что именно UpCore считает эффективностью и как нормализует разные проекты, стеки и типы задач;
- Можно ли автоматически определить грейд и трудоёмкость только по коду;
- Как в текущих условиях, когда код пишется с помощью ИИ, можно измерить эффективность программиста.
- Как отличить слабую работу от легаси, техдолга, сложного ядра системы и длительной отладки;
- На каких данных проверялись заявленные 85% точности и рост на 12%;
- Повышает ли полная прозрачность осознанность разработчика или разрушает доверие в команде;
- Как защитить такую систему от накрутки и саму команду - от ошибочных управленческих выводов;
- Где проходит граница между полезной инженерной телеметрией и цифровой слежкой.

#AI4SDLC #Engineering #Management #Leadership #Metrics #DevTools

SonarQube Cloud: зачем агентному коду детерминированный внешний контроль (Рубрика #AI4SDLC)

После поста "Sonar и звёздный час верификаторов" решил разобраться, а что именно SonarQube Cloud проверяет в коде, написанном агентами, а также почему это не еще один линтер, а что-то большее, например, гейт между тем, что «агент закончил» и «изменение можно влить».

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

- SonarQube - анализ и quality gates: Cloud работает в CI/CD, Server - в своем контуре, бесплатный SonarQube for IDE - во время написания кода.
- Gitar - AI-ревьюер pull request: разбирает сбои CI, предлагает и применяет исправления. Практически это экономия внимания на рутинном PR-ревью.
- Sonar Vortex - подает агенту контекст и правила через plugin, CLI или MCP и проверяет код во время генерации. Ошибки можно поймать до CI.
- Remediation Agent - исправляет issues из PR или backlog и открывает проверенный PR. Это автоматизация технического долга.
- Advanced Security - SCA: CVE, вредоносные зависимости, SBOM и лицензии. Это слой безопасности цепочки поставки.

Почему проверки в основном детерминированные? Проверяющий слой должен работать как турникет, а не как второй собеседник. При одинаковых исходниках, версии анализатора, профиле правил и отчетах результат повторяется. Это дает контракт для человека и coding agent, короткий цикл исправления и аудит: видно правило, строку и причину отказа.

Детерминированность не означает примитивность или точность. Анализатор строит модели потоков данных и путей исполнения, но они остаются приближением. Возможны ложные срабатывания и пропуски. Security Hotspots Sonar оставляет человеку: инструмент показывает чувствительное место, инженер оценивает контекст.

Зеленый Quality Gate не доказывает правильность бизнес-логики или архитектуры. Я бы разделял роли так: тесты проверяют ожидаемое поведение, Sonar - известные дефектные конструкции, человек - намерение и инженерные компромиссы.

Для меня главный вывод: чем дешевле генерация кода, тем важнее вынести критерии его приема из головы агента во внешний воспроизводимый контур. И защитить настройки, чтобы агент не мог «починить» красный gate снижением порога или исключением директории.

P.S.
Изучу еще CodeScene и дальше для своих пет проектов выберу один из этих продуктов и попробую на практике, потом поделюсь своими мыслями о том, а как они работают (благо сейчас я кода с агентами много пишу).

#AI4SDLC #AI #Agents #Engineering #DevSecOps #Evals