CTO 2026: от главного по технологиям к архитектору AI-native компании (Рубрика #Leadership)
В 2026 году роль CTO меняется радикально: теперь он отвечает не только за технологии, но и за то, как компания думает, учится и поставляет ценность в эпоху AI. Когда код, аналитика и прототипы становятся дешевле благодаря AI, главным дефицитом становятся контекст, качество решений, доверие и управляемая скорость. В своей статье я разбираю эти изменения и рассказываю о том, какие компетенции нужны техническому лидеру, чтобы не просто внедрять AI-инструменты, а перестраивать под них всю организацию.
Ну и напоследок я размышляю о том, а куда CTO стоит вести компанию в 2026 году, чтобы AI стал не модным слоем поверх процессов, а реальным рычагом роста и конкурентного преимущества.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
В 2026 году роль CTO меняется радикально: теперь он отвечает не только за технологии, но и за то, как компания думает, учится и поставляет ценность в эпоху AI. Когда код, аналитика и прототипы становятся дешевле благодаря AI, главным дефицитом становятся контекст, качество решений, доверие и управляемая скорость. В своей статье я разбираю эти изменения и рассказываю о том, какие компетенции нужны техническому лидеру, чтобы не просто внедрять AI-инструменты, а перестраивать под них всю организацию.
Ну и напоследок я размышляю о том, а куда CTO стоит вести компанию в 2026 году, чтобы AI стал не модным слоем поверх процессов, а реальным рычагом роста и конкурентного преимущества.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
Medium
От AI-native организации к AI-native лидерству: роль CTO в 2026 году
В предыдущих текстах этой серии я писал о переходе от классического PDLC к AI-native разработке, затем — к AI-native организации, дальше —…
👍11🥱6❤5🔥5🤔1
[1/2] Hands-On RAG for Production (Рубрика #AI)
С интересом прочел доступные главы этой книги, что находится в процессе написания. Основная идея авторов Ofer Mendelevitch и Forrest Bao была в том, чтобы рассказать про retrieval augmented generation как про инженерную систему и рассмотреть вопросы приема данных в платформу, прав доступа, latency ответов, автоматического оценивания, приватности и так далее. Это сильно отличает книгу от других, где RAG выглядит просто еще один паттерн поверх AI, но это и понятно, ведь авторы работают в Vectara, компании, что делает платформу для агентов, а также RAG as a service (поэтому и часть практических примеров в книге связана с этой платформой).
В общем, книга по задумке авторов попадает в самую болезненную точку рынка: разрыв между "демо работает" и «система переживает production, аудит, рост нагрузки и вопросы от security». Это и делает её важной не только для инженеров, но и для технических руководителей, не ради слова RAG, а ради инженерной дисциплины вокруг него (я примерно поэтому и взялся читать книгу). Если идти по доступным главам, то логика авторов прослеживается хорошо: сначала они собирают базу, а потом быстро уводят читателя из мира RAG на коленке в мир ограничений вокруг продакшена. Давайте посмотрим на главы пристальнее
1) "Introduction to Retrieval Augmented Generation (RAG)"
Это, по сути, фундамент: что RAG решает, где он реально лучше "голой" модели, и почему его так любят в enterprise-сценариях. Например, здесь автоы сравнивают RAG и fine-tuning моделей.
2) "Advanced RAG"
В этой главе начинается интересное обсуждение того, что отличает базовый pipeline от реально полезной системы. То есть не просто dense retrieval, а более сильный retrieval stack, reranking, chunking, query rewriting, гибридные схемы и прочая инженерия качества.
3 и 4) "Deploying RAG to Production" и "The RAG Platform" - это центральная часть книги. Именно здесь RAG перестаёт быть проектом на поиграться и становится системной задачей со своим набором ограничений и требований: latency, privacy, explainability, prompt design, compliance, доступы к данным, архитектурные компромиссы, build-vs-buy. А четвертая глава "The RAG Platform" особенно хороша тем, что показывает, что зрелый RAG почти всегда превращается не в одну фичу, а в платформенный слой, который начинает обслуживать несколько продуктов и команд.
В посте-продолжении я поделюсь мнением про оставшиеся главы книги и расскажу для кого она будет полезна.
#AI #Engineering #Software #DistributedSystems #SystemDesign #Database #Search #Agents
С интересом прочел доступные главы этой книги, что находится в процессе написания. Основная идея авторов Ofer Mendelevitch и Forrest Bao была в том, чтобы рассказать про retrieval augmented generation как про инженерную систему и рассмотреть вопросы приема данных в платформу, прав доступа, latency ответов, автоматического оценивания, приватности и так далее. Это сильно отличает книгу от других, где RAG выглядит просто еще один паттерн поверх AI, но это и понятно, ведь авторы работают в Vectara, компании, что делает платформу для агентов, а также RAG as a service (поэтому и часть практических примеров в книге связана с этой платформой).
В общем, книга по задумке авторов попадает в самую болезненную точку рынка: разрыв между "демо работает" и «система переживает production, аудит, рост нагрузки и вопросы от security». Это и делает её важной не только для инженеров, но и для технических руководителей, не ради слова RAG, а ради инженерной дисциплины вокруг него (я примерно поэтому и взялся читать книгу). Если идти по доступным главам, то логика авторов прослеживается хорошо: сначала они собирают базу, а потом быстро уводят читателя из мира RAG на коленке в мир ограничений вокруг продакшена. Давайте посмотрим на главы пристальнее
1) "Introduction to Retrieval Augmented Generation (RAG)"
Это, по сути, фундамент: что RAG решает, где он реально лучше "голой" модели, и почему его так любят в enterprise-сценариях. Например, здесь автоы сравнивают RAG и fine-tuning моделей.
2) "Advanced RAG"
В этой главе начинается интересное обсуждение того, что отличает базовый pipeline от реально полезной системы. То есть не просто dense retrieval, а более сильный retrieval stack, reranking, chunking, query rewriting, гибридные схемы и прочая инженерия качества.
3 и 4) "Deploying RAG to Production" и "The RAG Platform" - это центральная часть книги. Именно здесь RAG перестаёт быть проектом на поиграться и становится системной задачей со своим набором ограничений и требований: latency, privacy, explainability, prompt design, compliance, доступы к данным, архитектурные компромиссы, build-vs-buy. А четвертая глава "The RAG Platform" особенно хороша тем, что показывает, что зрелый RAG почти всегда превращается не в одну фичу, а в платформенный слой, который начинает обслуживать несколько продуктов и команд.
В посте-продолжении я поделюсь мнением про оставшиеся главы книги и расскажу для кого она будет полезна.
#AI #Engineering #Software #DistributedSystems #SystemDesign #Database #Search #Agents
O’Reilly Online Learning
Hands-On RAG for Production
Retrieval-augmented generation (RAG) is the go-to strategy for integrating large language models with your organization's unique knowledge. However, the market is full of RAG... - Selection from Hands-On RAG for Production [Book]
🔥9❤6👍4😁1
[2/2] Hands-On RAG for Production (Рубрика #AI)
Заканчивая обзор это крутой книги про RAG, что находится в процессе написания.
5) "Evaluating your RAG Application" - эта глава обязательна для прочтения тем, кто планирует докатить RAG на production. Авторы упоминают про метрики вроде hallucinations, response quality, latency и cost. И не только упоминают, но и рассказывают про способы измерения качества retrieval и генерации. По-факту, тут идет рассказ про стандартные метрики поиска (precision, recall, f1, метрики с учетом порядка элементов), а также про точность генерации (утилизация контекста, точность ответов, консистентность ответов, отсутствие галлюцинаций, точность цитат), а также предубеждения (по расе, полу и так далее). А также подходы к e2e оцениваниют при помощи фреймворков: Open-RAG-EVAL, RAGAs, DeepEval. Ну и напоследок как учитывать фидбек людей (условно пальцы вниз и вверх, которые вы видели в чатиках ChatGPT, Perplexity, ...)
6) "From RAG to AI Agents" - здесь речь идет про retrieval, который перестаёт быть конечным продуктом и становится частью более длинного workflow. То есть RAG - уже не только "найди и ответь", а "найди, проверь, спланируй, вызови инструмент, верни результат". Это очень верно для текущего времени, где агенты без качественного retrieval быстро превращаются в дорогую импровизацию.
7 и 8) "Multimodal RAG" и "Knowledge Enhanced RAG" делают книгу ещё полезнее для реальных корпораций. Это важно для всех, кто работает с PDF, таблицами, диаграммами, изображениями, полуструктурированными документами и сложными knowledge domains, где одной embedding similarity уже мало.
P.S.
Если сравнить эту книгу с другими, о которых я рассказывал, то получается такая картина
- "AI Engineering" - это широкая карта всей дисциплины и ответ на вопрос, а что вообще такое современная AI-разработка и из каких слоёв она состоит. На этом фоне "Hands-On RAG for Production" выглядит уже не как обзор всей системы, а как очень подробный разбор ее части - production RAG.
- "Prompt Engineering for LLMs" учит понимать архитектуру LLM, строить prompt strategy, правильно собирать context elements и использовать техники вроде few-shot, chain-of-thought и RAG. Поэтому "Prompt Engineering for LLMs" - это книга про интерфейс между человеком, контекстом и моделью, а "Hands-On RAG for Production" - про retrieval/platform layer, который этот контекст делает надёжным в проде.
#AI #Engineering #Software #DistributedSystems #SystemDesign #Database #Search #Agents
Заканчивая обзор это крутой книги про RAG, что находится в процессе написания.
5) "Evaluating your RAG Application" - эта глава обязательна для прочтения тем, кто планирует докатить RAG на production. Авторы упоминают про метрики вроде hallucinations, response quality, latency и cost. И не только упоминают, но и рассказывают про способы измерения качества retrieval и генерации. По-факту, тут идет рассказ про стандартные метрики поиска (precision, recall, f1, метрики с учетом порядка элементов), а также про точность генерации (утилизация контекста, точность ответов, консистентность ответов, отсутствие галлюцинаций, точность цитат), а также предубеждения (по расе, полу и так далее). А также подходы к e2e оцениваниют при помощи фреймворков: Open-RAG-EVAL, RAGAs, DeepEval. Ну и напоследок как учитывать фидбек людей (условно пальцы вниз и вверх, которые вы видели в чатиках ChatGPT, Perplexity, ...)
6) "From RAG to AI Agents" - здесь речь идет про retrieval, который перестаёт быть конечным продуктом и становится частью более длинного workflow. То есть RAG - уже не только "найди и ответь", а "найди, проверь, спланируй, вызови инструмент, верни результат". Это очень верно для текущего времени, где агенты без качественного retrieval быстро превращаются в дорогую импровизацию.
7 и 8) "Multimodal RAG" и "Knowledge Enhanced RAG" делают книгу ещё полезнее для реальных корпораций. Это важно для всех, кто работает с PDF, таблицами, диаграммами, изображениями, полуструктурированными документами и сложными knowledge domains, где одной embedding similarity уже мало.
P.S.
Если сравнить эту книгу с другими, о которых я рассказывал, то получается такая картина
- "AI Engineering" - это широкая карта всей дисциплины и ответ на вопрос, а что вообще такое современная AI-разработка и из каких слоёв она состоит. На этом фоне "Hands-On RAG for Production" выглядит уже не как обзор всей системы, а как очень подробный разбор ее части - production RAG.
- "Prompt Engineering for LLMs" учит понимать архитектуру LLM, строить prompt strategy, правильно собирать context elements и использовать техники вроде few-shot, chain-of-thought и RAG. Поэтому "Prompt Engineering for LLMs" - это книга про интерфейс между человеком, контекстом и моделью, а "Hands-On RAG for Production" - про retrieval/platform layer, который этот контекст делает надёжным в проде.
#AI #Engineering #Software #DistributedSystems #SystemDesign #Database #Search #Agents
Telegram
Книжный куб
[1/2] Hands-On RAG for Production (Рубрика #AI)
С интересом прочел доступные главы этой книги, что находится в процессе написания. Основная идея авторов Ofer Mendelevitch и Forrest Bao была в том, чтобы рассказать про retrieval augmented generation как про…
С интересом прочел доступные главы этой книги, что находится в процессе написания. Основная идея авторов Ofer Mendelevitch и Forrest Bao была в том, чтобы рассказать про retrieval augmented generation как про…
❤10👍6🔥1
Управление 2026 - Конференция от Стратоплана (Рубрика #Management)
В этом году мы наблюдаем как меняется все вокруг под воздействием AI, причем сама область разработки трансформируется быстрее всего. Меняются ожидания от линейных инженеров, но не только - и руководителям предстоит измениться. И логика тут простая: AI не заменит руководителей сам по себе - руководители, которые перестроились под новые условия, заменят тех, кто не захотел или не справился с этим.
И для тех, кто готов к изменениям мы решили провести конфу Управление’26 - она поможет тем, кто хочет свериться с реальностью и понять, какие компетенции и инструменты нужны, чтобы остаться востребованным сегодня и в будущем. Я на этой конфе расскажу про то, как меняется роль CTO, что ему стоит попробовать руками и как выстроить стратегию развития технологий компании, включая конечно и AI.
Регистрация на конфу доступна здесь, причем участие бесплатное при подписке на каналы спикеров (или если нет желания подписываться, то за символическую плату).
На конфе выступят: ex-CТО Bookmate и Pure, фаундер NEWHR, AI Program Manager из G42, Venture Principal, ex-PM в IBM и ex-CIO Volvo, и ex-Associate Managing Consultant в MasterCard + сооснователи Школы
Конференция пройдет с 20 по 23 апреля, онлайн (но будут доступны и записи).
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
В этом году мы наблюдаем как меняется все вокруг под воздействием AI, причем сама область разработки трансформируется быстрее всего. Меняются ожидания от линейных инженеров, но не только - и руководителям предстоит измениться. И логика тут простая: AI не заменит руководителей сам по себе - руководители, которые перестроились под новые условия, заменят тех, кто не захотел или не справился с этим.
И для тех, кто готов к изменениям мы решили провести конфу Управление’26 - она поможет тем, кто хочет свериться с реальностью и понять, какие компетенции и инструменты нужны, чтобы остаться востребованным сегодня и в будущем. Я на этой конфе расскажу про то, как меняется роль CTO, что ему стоит попробовать руками и как выстроить стратегию развития технологий компании, включая конечно и AI.
Регистрация на конфу доступна здесь, причем участие бесплатное при подписке на каналы спикеров (или если нет желания подписываться, то за символическую плату).
На конфе выступят: ex-CТО Bookmate и Pure, фаундер NEWHR, AI Program Manager из G42, Venture Principal, ex-PM в IBM и ex-CIO Volvo, и ex-Associate Managing Consultant в MasterCard + сооснователи Школы
Конференция пройдет с 20 по 23 апреля, онлайн (но будут доступны и записи).
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
👍18❤13🔥8🫡1
[1/2] SWE-PRBench: Benchmarking AI Code Review Quality Against Pull Request Feedback (Рубрика #Whitepaper)
Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя. В этом исследовании простая : SWE-Bench-подобные бенчмарки меряют, может ли модель написать правильный патч, а не может ли она оценить чужой PR как reviewer. И в предложенном подходе автор делает именно второе: берёт реальные merged PR и реальные комментарии людей в ревью как ground truth, не синтезирует комментарии и не сводит задачу к similarity текста. Плюс авторы фиксируют три режима контекста (по нарастающей), чтобы проверить эффект от его расширения
- config_A (diff + summary)
- config_B (добавлен file context)
- config_C (ещё и test/context layers)
Этот подход позволяет измерить насколько разные модели хороши в поиске issues в сравнении с находками людей.
Если глубже погружаться в методологию, то она такова
1) Сначала они отбирают репозитории по RQS (Repository Quality Score): review culture, свежесть PR, качество тестов/CI, объём PR activity и contamination proxy. Репозитории ниже 60/100 отбрасываются. Самый сильный сигнал - именно культура ревью: доля содержательных комментариев от людей в недавних merged PR.
2) Потом PR проходят 10-шаговую фильтрацию: только смердженные PR, минимум два содержательных человеческих комментария, есть изменения помимо тестов, не только изменения документации, не просто автоматический бамп зависимостей, не только AI ревью, diff можно распарсить, базовый commit доступен, репозиторий еще публичный, и проходит RVS-порог (что упоминался в первом пункте). Из примерно 3,000 raw PR остаётся 700 кандидатов, после RVS обрезается до 350 PR из 65 репозиториев. Ground truth берётся из реальных комментариев к ревью через GitHub API; комментарии не генерируются и не правятся вручную. Авторы отдельно фильтруют AI/bot комментарии и исключают PR, где AI-комментариев больше 30%.
3) Важная часть методологии построена вокруг таксономии сложности
- Type1 - проблема видна прямо в diff
- Type2 - нужно понимать окружающий код в том же файле и который не менялся
- Type3 - нужно размышление относительно кросс-файловых зависимостей
Этот ход превращает “качество code review” из одной мутной метрики в три разных когнитивных режима
4) Оценивание тоже сделано интересно. Агент должен вернуть 4–6 issues в JSON с severity, а judge-модель классифицирует каждый comment как CONFIRMED, PLAUSIBLE или FABRICATED. Причем PLAUSIBLE - это хороший подход, так как авторы признают, что ревью людьми не исчерпывающее, поэтому валидный новый комментарий не считается автоматом галлюцинацией. Дальше идёт маппинг, чтобы модель не получила двойные очки за разбиение одной идеи на пять комментариев, а итоговый score смешивает полноту, точность, semantic alignment, actionability и efficiency, штрафуя галлюцинации и избыточность.
В итоге, были получены интересные результаты:
1) На их 100-PR stratified sample ни одна модель не ловит больше 31% human-flagged issues; средний detection rate по всем 8 моделям на config_A примерно 26%. Топ-4 модели показывают примерно одинаковый агрегированный score.
2) По профилю моделей видим, что нет лучшего ревьювера и у нас обычный precision/recall trade-off. В цифрах DeepSeek V3 даёт лучший raw detection на config_A (DR=0.312), а GPT-4o даёт лучший hallucination profile (FPR=0.193). У Llama 3.3 70B худший FPR — 0.417.
3) Все 8 моделей деградируют при переходе от config_A к config_C. Причём config_A и config_C отличаются всего на 500 токенов (2,000 vs 2,500) - кажется, что проблема в том, как контекст подаётся, а не только в объёме.
4) Все ухудшается на переходе от config_A к config_B: у Sonnet score по Type2 падает с 0.22 до 0.10 при переходе A→B; у DeepSeek — с 0.20 до 0.10. То есть модели ломаются не там, где нужен весь репозиторий, а уже на шаге добавления окружающего контекста из измененного файла.
В продолжении обсудим что все это значит на практике.
#AI #Engineering #Software #SystemDesign #Agents
Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя. В этом исследовании простая : SWE-Bench-подобные бенчмарки меряют, может ли модель написать правильный патч, а не может ли она оценить чужой PR как reviewer. И в предложенном подходе автор делает именно второе: берёт реальные merged PR и реальные комментарии людей в ревью как ground truth, не синтезирует комментарии и не сводит задачу к similarity текста. Плюс авторы фиксируют три режима контекста (по нарастающей), чтобы проверить эффект от его расширения
- config_A (diff + summary)
- config_B (добавлен file context)
- config_C (ещё и test/context layers)
Этот подход позволяет измерить насколько разные модели хороши в поиске issues в сравнении с находками людей.
Если глубже погружаться в методологию, то она такова
1) Сначала они отбирают репозитории по RQS (Repository Quality Score): review culture, свежесть PR, качество тестов/CI, объём PR activity и contamination proxy. Репозитории ниже 60/100 отбрасываются. Самый сильный сигнал - именно культура ревью: доля содержательных комментариев от людей в недавних merged PR.
2) Потом PR проходят 10-шаговую фильтрацию: только смердженные PR, минимум два содержательных человеческих комментария, есть изменения помимо тестов, не только изменения документации, не просто автоматический бамп зависимостей, не только AI ревью, diff можно распарсить, базовый commit доступен, репозиторий еще публичный, и проходит RVS-порог (что упоминался в первом пункте). Из примерно 3,000 raw PR остаётся 700 кандидатов, после RVS обрезается до 350 PR из 65 репозиториев. Ground truth берётся из реальных комментариев к ревью через GitHub API; комментарии не генерируются и не правятся вручную. Авторы отдельно фильтруют AI/bot комментарии и исключают PR, где AI-комментариев больше 30%.
3) Важная часть методологии построена вокруг таксономии сложности
- Type1 - проблема видна прямо в diff
- Type2 - нужно понимать окружающий код в том же файле и который не менялся
- Type3 - нужно размышление относительно кросс-файловых зависимостей
Этот ход превращает “качество code review” из одной мутной метрики в три разных когнитивных режима
4) Оценивание тоже сделано интересно. Агент должен вернуть 4–6 issues в JSON с severity, а judge-модель классифицирует каждый comment как CONFIRMED, PLAUSIBLE или FABRICATED. Причем PLAUSIBLE - это хороший подход, так как авторы признают, что ревью людьми не исчерпывающее, поэтому валидный новый комментарий не считается автоматом галлюцинацией. Дальше идёт маппинг, чтобы модель не получила двойные очки за разбиение одной идеи на пять комментариев, а итоговый score смешивает полноту, точность, semantic alignment, actionability и efficiency, штрафуя галлюцинации и избыточность.
В итоге, были получены интересные результаты:
1) На их 100-PR stratified sample ни одна модель не ловит больше 31% human-flagged issues; средний detection rate по всем 8 моделям на config_A примерно 26%. Топ-4 модели показывают примерно одинаковый агрегированный score.
2) По профилю моделей видим, что нет лучшего ревьювера и у нас обычный precision/recall trade-off. В цифрах DeepSeek V3 даёт лучший raw detection на config_A (DR=0.312), а GPT-4o даёт лучший hallucination profile (FPR=0.193). У Llama 3.3 70B худший FPR — 0.417.
3) Все 8 моделей деградируют при переходе от config_A к config_C. Причём config_A и config_C отличаются всего на 500 токенов (2,000 vs 2,500) - кажется, что проблема в том, как контекст подаётся, а не только в объёме.
4) Все ухудшается на переходе от config_A к config_B: у Sonnet score по Type2 падает с 0.22 до 0.10 при переходе A→B; у DeepSeek — с 0.20 до 0.10. То есть модели ломаются не там, где нужен весь репозиторий, а уже на шаге добавления окружающего контекста из измененного файла.
В продолжении обсудим что все это значит на практике.
#AI #Engineering #Software #SystemDesign #Agents
arXiv.org
SWE-PRBench: Benchmarking AI Code Review Quality Against Pull...
We introduce SWE-PRBench, a benchmark of 350 pull requests with human-annotated ground truth for evaluating AI code review quality. Evaluated against an LLM-as-judge framework validated at...
❤6👍4🔥1🤔1
[2/2] SWE-PRBench: Benchmarking AI Code Review Quality Against Pull Request Feedback (Рубрика #Whitepaper)
Продолжая рассказ, про whitepaper мы поговорим какие практические выводы можно сделать из предложенного подхода.
1️⃣ Больше контекста, не всегда выше качество. В review-задаче компактный diff + summary оказался лучше, чем более “богатый” flat prompt. Я бы читал это не как “контекст бесполезен”, а как “наивная плоская упаковка контекста вредна”. Это важная разница: авторы сами пишут, что retrieval-based или token-level relevance strategies вроде changed-vs-unchanged markers могут дать другой результат, и прямо позиционируют config_B как uncurated baseline, относительно которого и надо мерить retrieval-approaches.
Отсюда мой практический вывод о том, что агент-ревьювер должен быть многошаговым, а не одним гигантским промптом. Нормальный pipeline может выгялдеть так:
- diff-only candidate generation;
- targeted retrieval только под подозрительные места;
- verifier/critic, который режет fabricated comments;
- dedup + severity ranking перед публикацией в PR.
Кажется, что это следующий шаг, который основан на результатах деградации качества по мере добавления контекста.
2️⃣ Не надо выбирать модель только по обобщенному скору. В этом исследовании top-4 модели почти не различимы статистически, зато у них разные результаты по части галлюцинаций и стоимости. Для бота, который пишет комменты прямо в PR, низкий FPR (false positive rate) обычно важнее, чем максимальный полнота; для ревьювера, что работает в shadow-mode можно взять более recall-heavy и дешёвый вариант, но обязательно с этапом верификации.
Если говорить про масштабирование подхода, то кажется сам подход отлично подходит для создания своих кастомных бенчей в компании.
- Data pipeline переносится в компанию почти напрямую: merged PR, diff, base/head SHA, changed files, human comments, frozen context fixtures, separate judge/agent pipeline
- У авторов уже опубликованы и dataset artifacts, и harness, где layout очень близок к тому, что и нужно внутри компании
- И в крупных компаниях это масштабируется даже лучше, чем в open source: внутри компании у вас обычно есть больше сигналов - ownership, CI артефакты, rollback history, incident links, review roles, labels вроде security/migration/data-contract.
То есть сам подход authors я бы не просто переносил, а усиливал внутренними metadata. Но production-часть paper переносить буквально я бы не стал: их собственные результаты показывают, что flat full-context review не работает, а limitations section прямо оставляет дверь открытой для более умных relevance encodings и retrieval.
А вот для переноса на всю индустрию пока есть препятствия
- Датасет Python-dominant (69.1%), performance PR почти нет (8), security PR вообще один, paper baseline посчитан на 100 PR из полного корпуса 350, а не на всём датасете
- Нет человеческого baseline в этом режиме, а judge-family bias authors сами не исключают.
#AI #Engineering #Software #SystemDesign #Agents
Продолжая рассказ, про whitepaper мы поговорим какие практические выводы можно сделать из предложенного подхода.
1️⃣ Больше контекста, не всегда выше качество. В review-задаче компактный diff + summary оказался лучше, чем более “богатый” flat prompt. Я бы читал это не как “контекст бесполезен”, а как “наивная плоская упаковка контекста вредна”. Это важная разница: авторы сами пишут, что retrieval-based или token-level relevance strategies вроде changed-vs-unchanged markers могут дать другой результат, и прямо позиционируют config_B как uncurated baseline, относительно которого и надо мерить retrieval-approaches.
Отсюда мой практический вывод о том, что агент-ревьювер должен быть многошаговым, а не одним гигантским промптом. Нормальный pipeline может выгялдеть так:
- diff-only candidate generation;
- targeted retrieval только под подозрительные места;
- verifier/critic, который режет fabricated comments;
- dedup + severity ranking перед публикацией в PR.
Кажется, что это следующий шаг, который основан на результатах деградации качества по мере добавления контекста.
2️⃣ Не надо выбирать модель только по обобщенному скору. В этом исследовании top-4 модели почти не различимы статистически, зато у них разные результаты по части галлюцинаций и стоимости. Для бота, который пишет комменты прямо в PR, низкий FPR (false positive rate) обычно важнее, чем максимальный полнота; для ревьювера, что работает в shadow-mode можно взять более recall-heavy и дешёвый вариант, но обязательно с этапом верификации.
Если говорить про масштабирование подхода, то кажется сам подход отлично подходит для создания своих кастомных бенчей в компании.
- Data pipeline переносится в компанию почти напрямую: merged PR, diff, base/head SHA, changed files, human comments, frozen context fixtures, separate judge/agent pipeline
- У авторов уже опубликованы и dataset artifacts, и harness, где layout очень близок к тому, что и нужно внутри компании
- И в крупных компаниях это масштабируется даже лучше, чем в open source: внутри компании у вас обычно есть больше сигналов - ownership, CI артефакты, rollback history, incident links, review roles, labels вроде security/migration/data-contract.
То есть сам подход authors я бы не просто переносил, а усиливал внутренними metadata. Но production-часть paper переносить буквально я бы не стал: их собственные результаты показывают, что flat full-context review не работает, а limitations section прямо оставляет дверь открытой для более умных relevance encodings и retrieval.
А вот для переноса на всю индустрию пока есть препятствия
- Датасет Python-dominant (69.1%), performance PR почти нет (8), security PR вообще один, paper baseline посчитан на 100 PR из полного корпуса 350, а не на всём датасете
- Нет человеческого baseline в этом режиме, а judge-family bias authors сами не исключают.
#AI #Engineering #Software #SystemDesign #Agents
Telegram
Книжный куб
[1/2] SWE-PRBench: Benchmarking AI Code Review Quality Against Pull Request Feedback (Рубрика #Whitepaper)
Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя.…
Когда разбирался с тем, как оценивать качество агентов внутри SDLC наткнулся на интересную и свежую работу от Deepak Kumar, независимого исследователя.…
👍5❤3🔥1
От AI-native разработки к AI-native платформе (Рубрика #AI4SDLC)
Написал статью про то, что следующее узкое место AI-native разработки лежит уже не в слое написания кода, а в самой платформе разработки. Как только агенты входят в основной рабочий поток, GitHub перестает быть просто местом хранения кода и запуска CI, а становится слоем управления для людей и агентов. Тогда ревью, проверки безопасности, политики и телеметрия перестают быть внешней обвязкой и становятся частью вычислительного пути.
На примере GitHub разбираю, как агентные сценарии создают новый класс платформенной нагрузки, почему защитные механизмы сами становятся частью основной нагрузки и что это означает для крупных инженерных организаций. Если совсем коротко, то AI ускоряет не только кодинг, но и рост давления на CI, ревью, проверки и путь до слияния. А значит, следующая зрелая форма AI-native - это уже не просто агент в IDE, а AI-native платформенная инженерия.
#AI #Architecture #Software #Engineering #Agents #Processes #Productivity
Написал статью про то, что следующее узкое место AI-native разработки лежит уже не в слое написания кода, а в самой платформе разработки. Как только агенты входят в основной рабочий поток, GitHub перестает быть просто местом хранения кода и запуска CI, а становится слоем управления для людей и агентов. Тогда ревью, проверки безопасности, политики и телеметрия перестают быть внешней обвязкой и становятся частью вычислительного пути.
На примере GitHub разбираю, как агентные сценарии создают новый класс платформенной нагрузки, почему защитные механизмы сами становятся частью основной нагрузки и что это означает для крупных инженерных организаций. Если совсем коротко, то AI ускоряет не только кодинг, но и рост давления на CI, ревью, проверки и путь до слияния. А значит, следующая зрелая форма AI-native - это уже не просто агент в IDE, а AI-native платформенная инженерия.
#AI #Architecture #Software #Engineering #Agents #Processes #Productivity
Medium
От AI-native разработки к AI-native платформе
Главное изменение в AI-native мире происходит не только в коде и не только в IDE. Оно происходит на уровне платформы: как только агенты…
❤7👍7🤔5👎2🔥2
Управление 2026 - Конференция от Стратоплана (Рубрика #Management)
В этом году мы наблюдаем как меняется все вокруг под воздействием AI, причем сама область разработки трансформируется быстрее всего. Меняются ожидания от линейных инженеров, но не только - и руководителям предстоит измениться. И логика тут простая: AI не заменит руководителей сам по себе - руководители, которые перестроились под новые условия, заменят тех, кто не захотел или не справился с этим.
И для тех, кто готов к изменениям мы решили провести конфу Управление’26 - она поможет тем, кто хочет свериться с реальностью и понять, какие компетенции и инструменты нужны, чтобы остаться востребованным сегодня и в будущем. Я на этой конфе расскажу про то, как меняется роль CTO, что ему стоит попробовать руками и как выстроить стратегию развития технологий компании, включая конечно и AI. По-факту, основная канва моего доклада будет опираться на серию моих статей
- От классического PDLC к AI-native разработке
- От AI-native разработки к AI-native организации (с примерами из опыта бигтехов)
- От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)
- Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году
- От AI-native разработки к AI-native платформе
- От AI-native организации к AI-native лидерству: роль CTO в 2026 году
Сама конфа пройдет с 20 по 23 апреля, а мое выступление будет в среду. Регистрация доступна здесь, причем участие бесплатное при подписке на каналы спикеров (или если нет желания подписываться, то за символическую плату). Для пропустивших будут доступны и записи выступлений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
В этом году мы наблюдаем как меняется все вокруг под воздействием AI, причем сама область разработки трансформируется быстрее всего. Меняются ожидания от линейных инженеров, но не только - и руководителям предстоит измениться. И логика тут простая: AI не заменит руководителей сам по себе - руководители, которые перестроились под новые условия, заменят тех, кто не захотел или не справился с этим.
И для тех, кто готов к изменениям мы решили провести конфу Управление’26 - она поможет тем, кто хочет свериться с реальностью и понять, какие компетенции и инструменты нужны, чтобы остаться востребованным сегодня и в будущем. Я на этой конфе расскажу про то, как меняется роль CTO, что ему стоит попробовать руками и как выстроить стратегию развития технологий компании, включая конечно и AI. По-факту, основная канва моего доклада будет опираться на серию моих статей
- От классического PDLC к AI-native разработке
- От AI-native разработки к AI-native организации (с примерами из опыта бигтехов)
- От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)
- Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году
- От AI-native разработки к AI-native платформе
- От AI-native организации к AI-native лидерству: роль CTO в 2026 году
Сама конфа пройдет с 20 по 23 апреля, а мое выступление будет в среду. Регистрация доступна здесь, причем участие бесплатное при подписке на каналы спикеров (или если нет желания подписываться, то за символическую плату). Для пропустивших будут доступны и записи выступлений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
Medium
От классического PDLC к AI-native разработке
На начало 2026 года разработка находится в переходной фазе. С одной стороны, у нас по‑прежнему доминирует классический процесс, построенный…
🔥17❤13👍6
AI Conf - AI в разработке: эффект, риски, реальность (Рубрика #AI)
Был вчера на конференции Олега Бунина AI Conf, где прошла дискуссия про AI в разработке, куда Олег пригласил большое количество технических топов. Тема обсуждения была заявлена интересной, поэтому я с удовольствием приехал послушать, повидать знакомых, а также пообщаться на эту тему в кулуарах. Как по мне дискуссия изначально крутилась вокруг "использовать AI в разработке" vs "не использовать AI в разработке", а в наше время это уже не вариант - индустрия уже ответила на этот вопрос и AI уже здесь. В итоге ближе ко второй половине дискуссии она сдвинулась в тему, а как именно эффективно использовать AI, что для этого нужно, а также какие сценарии работают и у кого. Забавно, что я был слушателем, но в какой-то момент у меня оказался в руках микрофон и мне тоже удалось поделиться своими мыслями, которые близки к тем моим статьям, что я упоминал в прошлом посте.
P.S.
Спасибо Олегу за приглашение на это мероприятие и в эту дискуссию, а также за то, что собрал такую интересную компанию.
Ну и спасибо всем ребятам, с которыми удалось пересечься на конфе и пообщаться на эти захватывающие темы - это отлично помогает понять кто и как подходит к решению похожих задач в разных компаниях.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
Был вчера на конференции Олега Бунина AI Conf, где прошла дискуссия про AI в разработке, куда Олег пригласил большое количество технических топов. Тема обсуждения была заявлена интересной, поэтому я с удовольствием приехал послушать, повидать знакомых, а также пообщаться на эту тему в кулуарах. Как по мне дискуссия изначально крутилась вокруг "использовать AI в разработке" vs "не использовать AI в разработке", а в наше время это уже не вариант - индустрия уже ответила на этот вопрос и AI уже здесь. В итоге ближе ко второй половине дискуссии она сдвинулась в тему, а как именно эффективно использовать AI, что для этого нужно, а также какие сценарии работают и у кого. Забавно, что я был слушателем, но в какой-то момент у меня оказался в руках микрофон и мне тоже удалось поделиться своими мыслями, которые близки к тем моим статьям, что я упоминал в прошлом посте.
P.S.
Спасибо Олегу за приглашение на это мероприятие и в эту дискуссию, а также за то, что собрал такую интересную компанию.
Ну и спасибо всем ребятам, с которыми удалось пересечься на конфе и пообщаться на эти захватывающие темы - это отлично помогает понять кто и как подходит к решению похожих задач в разных компаниях.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity
1❤9👍7🔥3👎1
CFP (Call For Papers) на JVM Day (Рубрика #Conference)
У нас есть традиция раз в год ...ходить в баню проводить конференцию JVM Day. На прошлой я даже выступал и мне дали джемпер с группой крови на рукаве надписью "Экспертно заявляю".
Если вы тоже хотите экспертно заявить о чем-то на сообщество бекендеров, то подавайте свою заявку на нашу конфу, что пройдет 29 августа в Москве.
Мы ждем заявки с интересными кейсами для стандартных 40 минутных докладов или дискуссий, а также у нас есть демозоны, где вы можете представить свой продукт и у вашей команды будет пространство с экранами и стойками на весь день: можно показывать технологию вживую, общаться с инженерами, собирать обратную связь и находить первых пользователей.
В общем, не стесняйтесь и оставляйте свои заявки.
#Conference #Software #Engineering
У нас есть традиция раз в год ...
Если вы тоже хотите экспертно заявить о чем-то на сообщество бекендеров, то подавайте свою заявку на нашу конфу, что пройдет 29 августа в Москве.
Мы ждем заявки с интересными кейсами для стандартных 40 минутных докладов или дискуссий, а также у нас есть демозоны, где вы можете представить свой продукт и у вашей команды будет пространство с экранами и стойками на весь день: можно показывать технологию вживую, общаться с инженерами, собирать обратную связь и находить первых пользователей.
В общем, не стесняйтесь и оставляйте свои заявки.
#Conference #Software #Engineering
❤4👏4🔥3😁3
The Great GPU Shortage – Rental Capacity – Launching our H100 1 Year Rental Price Index (Рубрика #AI)
Интересная статья от SemiAnalysis про агрессивный рынок аренды GPU, который вошел в клинч и цены взлетели вверх из-за роста спроса. Стоимость годового контракта на H100 выросла примерно на 40% - с $1.70 за GPU-час в октябре 2025 до $2.35 к марту 2026. On-demand capacity по сути выбрана по всем типам GPU, а Blackwell-кластеры, которые выходят в строй в середине 2026 года, во многих случаях уже заранее заняты. Даже найти кластер на 64 Hopper GPU стало нетривиально.
Авторы прямо связывает новую волну давления на рынок с резким ростом спроса на фоне agentic нагрузок поверх моделей. То есть узкое место теперь формируется не только гонкой лабораторий в тренировке новых моделей, а продакшен-инференсом, где модель перестаёт быть "чатом" и становится исполнителем рабочих процессов. В классическом chat UX экономика была относительно простой: один пользовательский запрос, один inference-pass, один ответ. В агентном мире одна задача раскладывается в дерево вызовов: оркестратор строит план, порождает субагентов, те параллельно ищут источники, читают код, ходят в инструменты, возвращают промежуточные результаты, после чего отдельный контур делает синтез, критику и верификацию. Например, cнаружи задача может выглядеть как "разбери инцидент" или "подготовь PR", а под капотом это уже рой субагентов.
В итоге, спрос на рынке растет уже не только от числа пользователей и не только от числа компаний, а скорее от того сколько задач делегируются агентам. Один и тот же разработчик, аналитик или исследователь теперь может запускать не один запрос к модели, а десятки координированных проходов - с длинным контекстом, ретраями, проверками и параллельными ветками. У мульти-агентных нагрузок есть неприятная для инфраструктуры особенность: они увеличивают не только суммарное потребление токенов, но и пиковую конкурентность, а это уже прямое давление на флот GPU.
Интересно, что этот спрос неравномерен. Авторы пишут, что часть inference-нагрузок, особенно большие MoE-сценарии, лучше работает на свежих системах вроде GB300 NVL72, тогда как тренировки и часть нагрузок, где важна стоимость к производительности, продолжают отлично жить на H100. Иными словами, новый агентный слой не просто "съедает Blackwell" - он одновременно поддерживает спрос и на Hopper, продлевая экономическую жизнь уже поставленных GPU. Поэтому у провайдеров сейчас не ценовая война за загрузку, а рынок продавца с длинными контрактами, предоплатой и выбором, кому вообще отдавать capacity.
Отсюда можно почерпнуть несколько выводов:
1️⃣ Планирование мощностей по модели "сколько у нас чатов в день" больше не работает - считать нужно fan-out на подагентов, глубину циклов верификации и уровень параллелизма (максимальный для задачи)
2️⃣ Юнит экономику надо считать не по запросам, а по выполненным задачам: агент может быть дорогим в токенах, но дешёвым относительно стоимости человека или цены задержки бизнес-процесса
3️⃣ Если ROI от AI-инструментов действительно остаётся кратно выше их стоимости, как пишет SemiAnalysis, то спрос на вычисления ещё долго будет слабо чувствителен к цене. А значит, рост GPU-потребления - это не временный всплеск хайпа, а новая реальность.
TLDR;
Раньше GPU в основном потребляли модели, а теперь GPU потребляют бизнес-процессы, разложенные на рой агентных подзадач. И именно мульти-агентные нагрузки могут оказаться главным скрытым драйвером нового дефицита вычислений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity #Agents #Economics
Интересная статья от SemiAnalysis про агрессивный рынок аренды GPU, который вошел в клинч и цены взлетели вверх из-за роста спроса. Стоимость годового контракта на H100 выросла примерно на 40% - с $1.70 за GPU-час в октябре 2025 до $2.35 к марту 2026. On-demand capacity по сути выбрана по всем типам GPU, а Blackwell-кластеры, которые выходят в строй в середине 2026 года, во многих случаях уже заранее заняты. Даже найти кластер на 64 Hopper GPU стало нетривиально.
Авторы прямо связывает новую волну давления на рынок с резким ростом спроса на фоне agentic нагрузок поверх моделей. То есть узкое место теперь формируется не только гонкой лабораторий в тренировке новых моделей, а продакшен-инференсом, где модель перестаёт быть "чатом" и становится исполнителем рабочих процессов. В классическом chat UX экономика была относительно простой: один пользовательский запрос, один inference-pass, один ответ. В агентном мире одна задача раскладывается в дерево вызовов: оркестратор строит план, порождает субагентов, те параллельно ищут источники, читают код, ходят в инструменты, возвращают промежуточные результаты, после чего отдельный контур делает синтез, критику и верификацию. Например, cнаружи задача может выглядеть как "разбери инцидент" или "подготовь PR", а под капотом это уже рой субагентов.
В итоге, спрос на рынке растет уже не только от числа пользователей и не только от числа компаний, а скорее от того сколько задач делегируются агентам. Один и тот же разработчик, аналитик или исследователь теперь может запускать не один запрос к модели, а десятки координированных проходов - с длинным контекстом, ретраями, проверками и параллельными ветками. У мульти-агентных нагрузок есть неприятная для инфраструктуры особенность: они увеличивают не только суммарное потребление токенов, но и пиковую конкурентность, а это уже прямое давление на флот GPU.
Интересно, что этот спрос неравномерен. Авторы пишут, что часть inference-нагрузок, особенно большие MoE-сценарии, лучше работает на свежих системах вроде GB300 NVL72, тогда как тренировки и часть нагрузок, где важна стоимость к производительности, продолжают отлично жить на H100. Иными словами, новый агентный слой не просто "съедает Blackwell" - он одновременно поддерживает спрос и на Hopper, продлевая экономическую жизнь уже поставленных GPU. Поэтому у провайдеров сейчас не ценовая война за загрузку, а рынок продавца с длинными контрактами, предоплатой и выбором, кому вообще отдавать capacity.
Отсюда можно почерпнуть несколько выводов:
1️⃣ Планирование мощностей по модели "сколько у нас чатов в день" больше не работает - считать нужно fan-out на подагентов, глубину циклов верификации и уровень параллелизма (максимальный для задачи)
2️⃣ Юнит экономику надо считать не по запросам, а по выполненным задачам: агент может быть дорогим в токенах, но дешёвым относительно стоимости человека или цены задержки бизнес-процесса
3️⃣ Если ROI от AI-инструментов действительно остаётся кратно выше их стоимости, как пишет SemiAnalysis, то спрос на вычисления ещё долго будет слабо чувствителен к цене. А значит, рост GPU-потребления - это не временный всплеск хайпа, а новая реальность.
TLDR;
Раньше GPU в основном потребляли модели, а теперь GPU потребляют бизнес-процессы, разложенные на рой агентных подзадач. И именно мульти-агентные нагрузки могут оказаться главным скрытым драйвером нового дефицита вычислений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity #Agents #Economics
Semianalysis
The Great GPU Shortage – Rental Capacity – Launching our H100 1 Year Rental Price Index
GPU Rental Pricing Dashboard Launch
25❤5🔥5💯5😁1🤨1
Measuring the effectiveness of software development tools and practices (Рубрика #Productivity)
Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.
Интересно, что у нас внутри Т-Банка тоже есть похожие подходы к расчетам, которые основаны на унификации процессов разработки и выделении уровня задач в командах, что приносят понятный бизнес-результат. Но давайте вернемся к оригинальной статье и посмотрим как работает подход авторов
1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки
Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты
2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели
У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера
3️⃣ Переходят от корреляции к причинности через causal inference
После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.
4️⃣ Добавляют "страховку" от переоценки эффекта AI
Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.
В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы
В будущем авторы хотят расширить модель, чтобы сравнивать архитектурные решения и давать рекомендации.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics
Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.
Интересно, что у нас внутри Т-Банка тоже есть похожие подходы к расчетам, которые основаны на унификации процессов разработки и выделении уровня задач в командах, что приносят понятный бизнес-результат. Но давайте вернемся к оригинальной статье и посмотрим как работает подход авторов
1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки
Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты
2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели
У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера
3️⃣ Переходят от корреляции к причинности через causal inference
После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.
4️⃣ Добавляют "страховку" от переоценки эффекта AI
Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.
В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы
В будущем авторы хотят расширить модель, чтобы сравнивать архитектурные решения и давать рекомендации.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics
Amazon Science
Measuring the effectiveness of software development tools and practices
New cost-to-serve-software metric that accounts for the full software development lifecycle helps determine which software development innovations provide quantifiable value.
1❤12👍5🔥2👎1🤔1
Atomic Heart: советская техноутопия, автономные роботы и мультиагентные системы (Рубрика #Games)
Недавно прошел игру Atomic Heart, и это оказался один из тех редких для меня случаев, когда я был готов играть в одиночном режиме, а не в кооперативе с женой или детьми:) Конкретно мне понравилось оказаться внутри огромной советской техноутопии, где роботы должны были освободить человека от рутины, а в итоге все сломалось примерно так, как ломается большая распределенная система, если у нее есть автономия, но плохо настроены ограничения, наблюдаемость и контур управления:) Особенно забавно проходить такую игру вечером, когда днем на работе занимаешься построением мультиагентных систем:)
Интересные моменты, что мне зашли
1️⃣ Это не просто игра про роботов, а игра про доверие к автономии
В Atomic Heart роботы изначально выглядят как продолжение мечты про автоматизацию: они работают на заводах, помогают людям, обслуживают инфраструктуру и вообще должны быть частью удобного мира будущего. Но когда система управления начинает вести себя не так, вся эта красота превращается в проблему с огромным радиусом поражения. И это очень знакомая инженерная мысль. В software engineering мы тоже все время пытаемся отдавать больше автономии системам: сервисам, платформам, AI-агентам, автоматическим пайплайнам, self-healing инфраструктуре. Но чем больше автономии, тем важнее вопросы governance: кто ставит цель, кто ограничивает действия, кто видит аномалии, как устроен kill switch и что будет, если локально разумное поведение глобально начнет разрушать систему.
2️⃣ Советская эстетика как часть идеи
Мне понравилось, что сеттинг СССР здесь не ощущается просто декоративной оберткой. Это не "давайте нарисуем плакаты и поставим роботов на фоне серпа и молота". В игре сама идея будущего выглядит очень по-советски: единая большая система, централизованная научная программа, вера в инженерный прогресс, заводы как храмы модерна, человек как часть большого проекта. Если киберпанк часто рассказывает про корпорации, рынок и приватизированное будущее, то Atomic Heart скорее рассказывает про другую версию техноутопии: будущее как централизованная платформа. Почти госплан для роботов, нейросетей и автоматизированного быта.
3️⃣ Геймплей хорошо поддерживает ощущение системного сбоя
В игре ты постоянно чувствуешь, что находишься не просто на наборе уровней, а внутри большой инфраструктуры, у которой случился каскадный сбой. Камеры, локальные контуры безопасности, ремонтные дроны, роботы, которые возвращаются в строй, лаборатории, полигоны, подземные комплексы - все это создает ощущение живой, но враждебной системы. И это как раз одна из причин, почему одиночный режим здесь хорошо работает. В кооперативе было бы веселее, но потерялась бы важная часть атмосферы: ты один, вокруг автономные системы, не все объяснения надежны, а твой помощник в перчатке слишком много знает про происходящее, чтобы ему просто верить.
4️⃣ В игре хорошо показана цена красивой техноутопии
Atomic Heart постоянно играет на контрасте: солнечные парки, музыка, красивые здания, счастливые лозунги, и рядом - мертвые сотрудники, лабораторный хаос, биомеханические эксперименты и роботы, которые вместо помощи начинают устранять людей как источник проблемы. Это довольно сильная метафора для любой большой технологической программы. Пока система работает, все говорят про эффективность, автоматизацию и новый уровень жизни. Но когда она ломается, внезапно выясняется, что важны не только возможности, но и отказоустойчивость, безопасность, права доступа, аудит, границы ответственности и способность остановить систему до того, как она начнет масштабировать ошибку.
В общем, Atomic Heart мне понравился не только как шутер, а скорее как интересное погружение в мир автономных роботов, построенных явно не на трех законах робототехники Айзека Азимова:)
#Games #AI #Robotics #Agents #Architecture #Software #SystemDesign
Недавно прошел игру Atomic Heart, и это оказался один из тех редких для меня случаев, когда я был готов играть в одиночном режиме, а не в кооперативе с женой или детьми:) Конкретно мне понравилось оказаться внутри огромной советской техноутопии, где роботы должны были освободить человека от рутины, а в итоге все сломалось примерно так, как ломается большая распределенная система, если у нее есть автономия, но плохо настроены ограничения, наблюдаемость и контур управления:) Особенно забавно проходить такую игру вечером, когда днем на работе занимаешься построением мультиагентных систем:)
Интересные моменты, что мне зашли
1️⃣ Это не просто игра про роботов, а игра про доверие к автономии
В Atomic Heart роботы изначально выглядят как продолжение мечты про автоматизацию: они работают на заводах, помогают людям, обслуживают инфраструктуру и вообще должны быть частью удобного мира будущего. Но когда система управления начинает вести себя не так, вся эта красота превращается в проблему с огромным радиусом поражения. И это очень знакомая инженерная мысль. В software engineering мы тоже все время пытаемся отдавать больше автономии системам: сервисам, платформам, AI-агентам, автоматическим пайплайнам, self-healing инфраструктуре. Но чем больше автономии, тем важнее вопросы governance: кто ставит цель, кто ограничивает действия, кто видит аномалии, как устроен kill switch и что будет, если локально разумное поведение глобально начнет разрушать систему.
2️⃣ Советская эстетика как часть идеи
Мне понравилось, что сеттинг СССР здесь не ощущается просто декоративной оберткой. Это не "давайте нарисуем плакаты и поставим роботов на фоне серпа и молота". В игре сама идея будущего выглядит очень по-советски: единая большая система, централизованная научная программа, вера в инженерный прогресс, заводы как храмы модерна, человек как часть большого проекта. Если киберпанк часто рассказывает про корпорации, рынок и приватизированное будущее, то Atomic Heart скорее рассказывает про другую версию техноутопии: будущее как централизованная платформа. Почти госплан для роботов, нейросетей и автоматизированного быта.
3️⃣ Геймплей хорошо поддерживает ощущение системного сбоя
В игре ты постоянно чувствуешь, что находишься не просто на наборе уровней, а внутри большой инфраструктуры, у которой случился каскадный сбой. Камеры, локальные контуры безопасности, ремонтные дроны, роботы, которые возвращаются в строй, лаборатории, полигоны, подземные комплексы - все это создает ощущение живой, но враждебной системы. И это как раз одна из причин, почему одиночный режим здесь хорошо работает. В кооперативе было бы веселее, но потерялась бы важная часть атмосферы: ты один, вокруг автономные системы, не все объяснения надежны, а твой помощник в перчатке слишком много знает про происходящее, чтобы ему просто верить.
4️⃣ В игре хорошо показана цена красивой техноутопии
Atomic Heart постоянно играет на контрасте: солнечные парки, музыка, красивые здания, счастливые лозунги, и рядом - мертвые сотрудники, лабораторный хаос, биомеханические эксперименты и роботы, которые вместо помощи начинают устранять людей как источник проблемы. Это довольно сильная метафора для любой большой технологической программы. Пока система работает, все говорят про эффективность, автоматизацию и новый уровень жизни. Но когда она ломается, внезапно выясняется, что важны не только возможности, но и отказоустойчивость, безопасность, права доступа, аудит, границы ответственности и способность остановить систему до того, как она начнет масштабировать ошибку.
В общем, Atomic Heart мне понравился не только как шутер, а скорее как интересное погружение в мир автономных роботов, построенных явно не на трех законах робототехники Айзека Азимова:)
#Games #AI #Robotics #Agents #Architecture #Software #SystemDesign
Mundfish
https://mundfish.com
👍21🔥13❤11
Object Oriented Design Interview: An Insider’s Guide (Рубрика #SystemDesign)
Эта книга вышла в 2025 году как продолжение линейки “Insider’s Guide” от ByteByteGo, но уже не про высокоуровневый system design, а про более низкоуровневый объектно-ориентированный дизайн (OOD, object-oriented design), где идеи превращаются в классы, интерфейсы, состояния, потоки выполнения и так далее. Интересно, что уже почти готов и перевод от издательства Питер причем с моим отзывом на обложке книги:)
Авторами книги являются трио: Fawaz Bokhari, Alex Xu и Desmond Zhou, в котором Alex Xu известен лучше всего по начальной серии "System Design Interview: An Insider’s Guide", про которую я уже рассказывал (и которая теперь есть в разборе на system-design.space). В этой книге авторы решили рассказать про новый тип интервью, где проверяются умение строить логичные, расширяемые и поддерживаемые системы, применять принципы ООП и паттерны, а не просто писать синтаксически корректный код. Среди примеров, где используются такие интервью упоминаются Amazon, Bloomberg и Uber.
Книга выглядит как тренажер для кандидата, который получает три важные вещи
1️⃣ Рамка решения OOD-задач
В книге заявлен 4-шаговый фреймворк для любой object-oriented design задачи:
- Понять требования
- Выделить сущности и связи
- Продумать взаимодействия
- Уточнить дизайн и edge cases
2️⃣ Набор типовых задач
В книге 11 реальных OOD interview questions с подробными решениями: Parking Lot, Movie Ticket Booking, Unix File Search, Vending Machine, Elevator, Grocery Store, Tic-Tac-Toe, Blackjack, Shipping Locker, ATM и Restaurant Management System
3️⃣ Визуальная модель проектирования
В книге приведены 133 диаграммы, которые объясняют архитектуру, workflows и связи между частями системы. В общем, именно визуальная составляющая на интервью ясно кандидат показывает ответственности, границы, состояния и взаимодействия.
Первые три главы книги дают базовое понимание про объектно-ориентированное интервью, как к нему подходить и какие базовые принципы надо держать в голове. А следующие главы уже содержат конкретные задачи, которые можно использовать при подготовке. На каждой задаче стоит делать паузу до чтения решения: самому набросать классы, интерфейсы, последовательность вызовов и основные edge cases. Только после этого сравнивать с авторским решением.
Если смотреть на другие типы интервью, то объектно-ориентированный дизайн - это что-то посередине между кодинговым интервью и системным дизайном. Это уже выше по абстракции написания алгоритмов, но все еще про написание кода внутри сервисов. В этой схеме system design - это про то, какие сервисы есть, как они общаются, где хранятся данные и так далее. А вот low-level или объектно ориентированный дизайн отвечает: какие объекты живут внутри сервиса, кто за что отвечает, какие состояния возможны, где инварианты, как добавлять новые сценарии без переписывания всего кода. Поэтому книга хорошо дополняет классический System Design. Она не заменяет знания про distributed systems, но помогает довести архитектурную идею до уровня, на котором её реально можно реализовать.
#SystemDesign #OOD #Architecture #Interview #Software #Engineering
Эта книга вышла в 2025 году как продолжение линейки “Insider’s Guide” от ByteByteGo, но уже не про высокоуровневый system design, а про более низкоуровневый объектно-ориентированный дизайн (OOD, object-oriented design), где идеи превращаются в классы, интерфейсы, состояния, потоки выполнения и так далее. Интересно, что уже почти готов и перевод от издательства Питер причем с моим отзывом на обложке книги:)
Авторами книги являются трио: Fawaz Bokhari, Alex Xu и Desmond Zhou, в котором Alex Xu известен лучше всего по начальной серии "System Design Interview: An Insider’s Guide", про которую я уже рассказывал (и которая теперь есть в разборе на system-design.space). В этой книге авторы решили рассказать про новый тип интервью, где проверяются умение строить логичные, расширяемые и поддерживаемые системы, применять принципы ООП и паттерны, а не просто писать синтаксически корректный код. Среди примеров, где используются такие интервью упоминаются Amazon, Bloomberg и Uber.
Книга выглядит как тренажер для кандидата, который получает три важные вещи
1️⃣ Рамка решения OOD-задач
В книге заявлен 4-шаговый фреймворк для любой object-oriented design задачи:
- Понять требования
- Выделить сущности и связи
- Продумать взаимодействия
- Уточнить дизайн и edge cases
2️⃣ Набор типовых задач
В книге 11 реальных OOD interview questions с подробными решениями: Parking Lot, Movie Ticket Booking, Unix File Search, Vending Machine, Elevator, Grocery Store, Tic-Tac-Toe, Blackjack, Shipping Locker, ATM и Restaurant Management System
3️⃣ Визуальная модель проектирования
В книге приведены 133 диаграммы, которые объясняют архитектуру, workflows и связи между частями системы. В общем, именно визуальная составляющая на интервью ясно кандидат показывает ответственности, границы, состояния и взаимодействия.
Первые три главы книги дают базовое понимание про объектно-ориентированное интервью, как к нему подходить и какие базовые принципы надо держать в голове. А следующие главы уже содержат конкретные задачи, которые можно использовать при подготовке. На каждой задаче стоит делать паузу до чтения решения: самому набросать классы, интерфейсы, последовательность вызовов и основные edge cases. Только после этого сравнивать с авторским решением.
Если смотреть на другие типы интервью, то объектно-ориентированный дизайн - это что-то посередине между кодинговым интервью и системным дизайном. Это уже выше по абстракции написания алгоритмов, но все еще про написание кода внутри сервисов. В этой схеме system design - это про то, какие сервисы есть, как они общаются, где хранятся данные и так далее. А вот low-level или объектно ориентированный дизайн отвечает: какие объекты живут внутри сервиса, кто за что отвечает, какие состояния возможны, где инварианты, как добавлять новые сценарии без переписывания всего кода. Поэтому книга хорошо дополняет классический System Design. Она не заменяет знания про distributed systems, но помогает довести архитектурную идею до уровня, на котором её реально можно реализовать.
#SystemDesign #OOD #Architecture #Interview #Software #Engineering
👍12🔥5⚡2❤2😘1
[1/2] Ranking Engineer Agent: как Meta превращает ML-эксперименты в автономный контур разработки моделей (Рубрика #AI)
С интересом прочел мартовскуюстатью запрещенной в России компании Meta про Ranking Engineer Agent, или REA. Это внутренний агент, который помогает развивать ads ranking модели: сам генерирует гипотезы, запускает тренировочные джобы, дебажит ошибки, анализирует результаты и идет на следующий цикл экспериментов. То есть это уже не copilot, который помогает инженеру на одном шаге, а агент, который пытается закрыть длинный инженерный workflow от идеи до кандидата на улучшение модели.
Суть в том, что бутылочное горлышко в ML-разработке у зрелых компаний давно находится не только в качестве моделей, а в скорости и дисциплине экспериментов. В обычном процессе инженер придумывает гипотезу, собирает конфиг, запускает обучение, ждет часы или дни, разбирает ошибки, смотрит метрики, делает выводы и повторяет цикл. Каждый такой оборот может занимать дни или недели, а на зрелых ranking-моделях значимые улучшения становится находить всё сложнее. Meta прямо пишет, что ручной и последовательный характер ML-экспериментов стал ограничением для инноваций.
REA интересен тем, что он атакует не отдельный шаг, а весь цикл. У него есть долгоживущее состояние, память по прошлым экспериментам, доступ к инфраструктурным инструментам, механизм ожидания долгих задач и guardrails по бюджету, правам и эскалациям. По сути, Meta делает из ML-экспериментирования управляемый производственный контур, который дает следующие возможности
1️⃣ Он снимает с инженера механику экспериментов
Запуск обучения, мониторинг, первичный дебаг инфраструктурных ошибок, сбор результатов, логирование выводов и подготовка следующей итерации - всё это типичная работа, которая важна, но плохо масштабируется вниманием человека.
2️⃣ Он позволяет вести много длинных экспериментов параллельно
Training job может идти часами или днями. Обычный чат-ассистент на этом месте просто “заканчивается”, потому что он ограничен длинной сессии. REA умеет уснуть после запуска задачи и проснуться, когда результаты готовы.
3️⃣ Он накапливает институциональную память
Каждый эксперимент попадает в базу инсайтов: какие гипотезы пробовали, какие конфиги работали, какие ошибки возникали, какие метрики получались. Это важно, потому что зрелая ML-разработка очень быстро превращается в задачу про память организации, а не только про талант отдельных инженеров.
4️⃣ Он повышает пропускную способность инженеров и повышает качество артефактов
В первой раскатке в прод Meta получила, по своим данным, 2x рост средней model accuracy относительно baseline по шести моделям и 5x рост пропускной способности: три инженера подготовили предложения по улучшению восьми моделей, тогда как раньше похожая работа требовала примерно двух инженеров на модель.
Я бы, конечно, аккуратно относился к таким цифрам, потому что это внутренние метрики Meta и конкретный домен ads ranking, но это уже не про токены, а про пропускную способность команд и качество их работы (метрики точности моделей).
В следующем посте я расскажу немного про то, как устроен этот агент.
#AI #Agents #Engineering #ML #Architecture #DevEx #Productivity #Management #Software #SystemDesign
С интересом прочел мартовскуюстатью запрещенной в России компании Meta про Ranking Engineer Agent, или REA. Это внутренний агент, который помогает развивать ads ranking модели: сам генерирует гипотезы, запускает тренировочные джобы, дебажит ошибки, анализирует результаты и идет на следующий цикл экспериментов. То есть это уже не copilot, который помогает инженеру на одном шаге, а агент, который пытается закрыть длинный инженерный workflow от идеи до кандидата на улучшение модели.
Суть в том, что бутылочное горлышко в ML-разработке у зрелых компаний давно находится не только в качестве моделей, а в скорости и дисциплине экспериментов. В обычном процессе инженер придумывает гипотезу, собирает конфиг, запускает обучение, ждет часы или дни, разбирает ошибки, смотрит метрики, делает выводы и повторяет цикл. Каждый такой оборот может занимать дни или недели, а на зрелых ranking-моделях значимые улучшения становится находить всё сложнее. Meta прямо пишет, что ручной и последовательный характер ML-экспериментов стал ограничением для инноваций.
REA интересен тем, что он атакует не отдельный шаг, а весь цикл. У него есть долгоживущее состояние, память по прошлым экспериментам, доступ к инфраструктурным инструментам, механизм ожидания долгих задач и guardrails по бюджету, правам и эскалациям. По сути, Meta делает из ML-экспериментирования управляемый производственный контур, который дает следующие возможности
1️⃣ Он снимает с инженера механику экспериментов
Запуск обучения, мониторинг, первичный дебаг инфраструктурных ошибок, сбор результатов, логирование выводов и подготовка следующей итерации - всё это типичная работа, которая важна, но плохо масштабируется вниманием человека.
2️⃣ Он позволяет вести много длинных экспериментов параллельно
Training job может идти часами или днями. Обычный чат-ассистент на этом месте просто “заканчивается”, потому что он ограничен длинной сессии. REA умеет уснуть после запуска задачи и проснуться, когда результаты готовы.
3️⃣ Он накапливает институциональную память
Каждый эксперимент попадает в базу инсайтов: какие гипотезы пробовали, какие конфиги работали, какие ошибки возникали, какие метрики получались. Это важно, потому что зрелая ML-разработка очень быстро превращается в задачу про память организации, а не только про талант отдельных инженеров.
4️⃣ Он повышает пропускную способность инженеров и повышает качество артефактов
В первой раскатке в прод Meta получила, по своим данным, 2x рост средней model accuracy относительно baseline по шести моделям и 5x рост пропускной способности: три инженера подготовили предложения по улучшению восьми моделей, тогда как раньше похожая работа требовала примерно двух инженеров на модель.
Я бы, конечно, аккуратно относился к таким цифрам, потому что это внутренние метрики Meta и конкретный домен ads ranking, но это уже не про токены, а про пропускную способность команд и качество их работы (метрики точности моделей).
В следующем посте я расскажу немного про то, как устроен этот агент.
#AI #Agents #Engineering #ML #Architecture #DevEx #Productivity #Management #Software #SystemDesign
Engineering at Meta
Ranking Engineer Agent (REA): The Autonomous AI Agent Accelerating Meta’s Ads Ranking Innovation
Meta’s Ranking Engineer Agent (REA) autonomously executes key steps across the end-to-end machine learning (ML) lifecycle for ads ranking models. This post covers REA’s ML experimentation capabilit…
❤7🔥2
[2/2] Ranking Engineer Agent: как Meta превращает ML-эксперименты в автономный контур разработки моделей (Рубрика #AI)
Продолжая рассказ про ML-агента от запрещенной в России компании Meta, надо рассказать про его архитектуру и устройство. Но начать надо с основных концепций
1️⃣ Hibernate-and-wake mechanism
Когда агент запускает долгую training job, он не держит активную сессию, а передает ожидание фоновой системе, сохраняет состояние и потом автоматически продолжает работу после завершения job. Это выглядит как важный паттерн для всех production-агентов, которые работают не с быстрым “ответь на вопрос”, а с процессами на часы, дни и недели.
2️⃣ Dual-source hypothesis engine
Гипотезы генерируются не только из головы LLM. REA опирается на два источника:
- Historical insights database - базу прошлых экспериментов, успехов и неудач;
- ML Research Agent - компонент, который исследует baseline-конфигурации и предлагает новые стратегии оптимизации.
3️⃣ Трехфазный planning framework
Перед запуском REA предлагает exploration strategy, оценивает GPU cost и согласует подход с инженером. Дальше план обычно идет в три этапа:
- Validation - проверка отдельных гипотез;
- Combination - комбинирование перспективных гипотез;
- Exploitation - более агрессивная оптимизация лучших кандидатов в рамках согласованного бюджета.
4️⃣ Planner + Executor
Внутри агент разделен на планировщика и исполнителя: REA Planner и REA Executor. Planner помогает сформировать план экспериментов, а Executor занимается асинхронным выполнением: запускает jobs, ждет, собирает результаты, обрабатывает ошибки и возвращает planner’у уже actionable output.
5️⃣ Skills, Knowledge and Tool System
REA подключен к внутренним инструментам Meta: job schedulers, experiment tracking, codebase navigation и другим системам. Плюс он работает на внутреннем agent framework Confucius (есть отдельный whitepaper), который как раз рассчитан на долгие многошаговые задачи в больших кодовых базах.
6️⃣ Guardrails и runbooks
Когда агент сталкивается с OOM (out of memory), loss explosion, инфраструктурной ошибкой или плохими результатами, он не зовет инженера по каждому поводу. Он сверяется с runbook’ом типовых проблем и действует в рамках заранее заданных ограничений. Но при этом доступы, preflight checklist, compute budget и остановка при превышении лимитов остаются под контролем людей.
В общем, REA - это связка из агента, памяти, инструментов, очередей, бюджетов, метрик, runbooks и точек контроля. Именно это отличает его от демки и делает production-системой.
У ребят из Meta есть дальнейшие план по развитию этого агента:
- Fine-tuning специализированных моделей для генерации гипотез
- Расширение аналитических инструментов
- Усиление privacy/security/governance
- Перенос подхода на новые домены
И это уже начало происходить. В следующем посте серии Meta рассказала про KernelEvolve - агентную систему для оптимизации низкоуровневых kernels под разные accelerator’ы: NVIDIA GPU, AMD GPU, MTIA и CPU. Там логика похожая: не one-shot генерация кода, а поиск по множеству вариантов, автоматическая проверка correctness/performance, профилирование и итерации. Meta пишет, что KernelEvolve дал более 60% improvement inference throughput для Andromeda Ads model на NVIDIA GPU и более 25% training throughput improvement для ads model на MTIA.
То есть траектория понятна: сначала агент помогает находить лучшие модели, потом помогает делать их production-ready через оптимизацию инфраструктуры, а дальше похожие agentic-подходы можно переносить на compiler optimization, memory management, system configuration и другие инженерные контуры.
#AI #Agents #Engineering #ML #Architecture #DevEx #Productivity #Management #Software #SystemDesign
Продолжая рассказ про ML-агента от запрещенной в России компании Meta, надо рассказать про его архитектуру и устройство. Но начать надо с основных концепций
1️⃣ Hibernate-and-wake mechanism
Когда агент запускает долгую training job, он не держит активную сессию, а передает ожидание фоновой системе, сохраняет состояние и потом автоматически продолжает работу после завершения job. Это выглядит как важный паттерн для всех production-агентов, которые работают не с быстрым “ответь на вопрос”, а с процессами на часы, дни и недели.
2️⃣ Dual-source hypothesis engine
Гипотезы генерируются не только из головы LLM. REA опирается на два источника:
- Historical insights database - базу прошлых экспериментов, успехов и неудач;
- ML Research Agent - компонент, который исследует baseline-конфигурации и предлагает новые стратегии оптимизации.
3️⃣ Трехфазный planning framework
Перед запуском REA предлагает exploration strategy, оценивает GPU cost и согласует подход с инженером. Дальше план обычно идет в три этапа:
- Validation - проверка отдельных гипотез;
- Combination - комбинирование перспективных гипотез;
- Exploitation - более агрессивная оптимизация лучших кандидатов в рамках согласованного бюджета.
4️⃣ Planner + Executor
Внутри агент разделен на планировщика и исполнителя: REA Planner и REA Executor. Planner помогает сформировать план экспериментов, а Executor занимается асинхронным выполнением: запускает jobs, ждет, собирает результаты, обрабатывает ошибки и возвращает planner’у уже actionable output.
5️⃣ Skills, Knowledge and Tool System
REA подключен к внутренним инструментам Meta: job schedulers, experiment tracking, codebase navigation и другим системам. Плюс он работает на внутреннем agent framework Confucius (есть отдельный whitepaper), который как раз рассчитан на долгие многошаговые задачи в больших кодовых базах.
6️⃣ Guardrails и runbooks
Когда агент сталкивается с OOM (out of memory), loss explosion, инфраструктурной ошибкой или плохими результатами, он не зовет инженера по каждому поводу. Он сверяется с runbook’ом типовых проблем и действует в рамках заранее заданных ограничений. Но при этом доступы, preflight checklist, compute budget и остановка при превышении лимитов остаются под контролем людей.
В общем, REA - это связка из агента, памяти, инструментов, очередей, бюджетов, метрик, runbooks и точек контроля. Именно это отличает его от демки и делает production-системой.
У ребят из Meta есть дальнейшие план по развитию этого агента:
- Fine-tuning специализированных моделей для генерации гипотез
- Расширение аналитических инструментов
- Усиление privacy/security/governance
- Перенос подхода на новые домены
И это уже начало происходить. В следующем посте серии Meta рассказала про KernelEvolve - агентную систему для оптимизации низкоуровневых kernels под разные accelerator’ы: NVIDIA GPU, AMD GPU, MTIA и CPU. Там логика похожая: не one-shot генерация кода, а поиск по множеству вариантов, автоматическая проверка correctness/performance, профилирование и итерации. Meta пишет, что KernelEvolve дал более 60% improvement inference throughput для Andromeda Ads model на NVIDIA GPU и более 25% training throughput improvement для ads model на MTIA.
То есть траектория понятна: сначала агент помогает находить лучшие модели, потом помогает делать их production-ready через оптимизацию инфраструктуры, а дальше похожие agentic-подходы можно переносить на compiler optimization, memory management, system configuration и другие инженерные контуры.
#AI #Agents #Engineering #ML #Architecture #DevEx #Productivity #Management #Software #SystemDesign
Telegram
Книжный куб
[1/2] Ranking Engineer Agent: как Meta превращает ML-эксперименты в автономный контур разработки моделей (Рубрика #AI)
С интересом прочел мартовскуюстатью запрещенной в России компании Meta про Ranking Engineer Agent, или REA. Это внутренний агент, который…
С интересом прочел мартовскуюстатью запрещенной в России компании Meta про Ranking Engineer Agent, или REA. Это внутренний агент, который…
❤4🔥3👍2
[1/3] System Design. Подготовка к сложному интервью по GenAI (Рубрика #SystemDesign)
Изучил интересную книгу для подготовки к интервью по System Design, но уже в новой реальности, когда проектировать надо не только базы, очереди, кэши и микросервисы, но и системы вокруг LLM, diffusion models, RAG, мультимодальных моделей и AI-powered продуктов. Это русское издание книги "Generative AI System Design Interview" из экосистемы ByteByteGo. Авторы - Али Аминиан и Хао Шенг. Али Аминиан уже известен по книге про ML System Design Interview, а здесь фокус смещается с классических ML-систем вроде поиска и рекомендаций на генеративный AI: чатботы, генерацию текста, изображений, видео, RAG и персонализированные AI-сценарии.
В обычном System Design Interview кандидат часто рисует распределенную систему: API, балансировщики, базы данных, очереди, кэши, фоновые джобы, мониторинг. В GenAI-интервью все это остается, но появляется еще один слой сложности:
- Какие данные нужны;
- Какую модель выбрать;
- Нужен ли RAG или fine-tuning;
- Как измерять качество генерации;
- Как бороться с hallucinations;
- Как учитывать latency и стоимость инференса;
- Как встроить safety-фильтры;
- Как собирать feedback loop;
- Как мониторить деградацию системы после запуска.
Именно поэтому книга полезна не только ML-инженерам. Она хорошо ложится и на backend engineers, и на архитекторов, и на технических руководителей, которым сейчас приходится проектировать AI-фичи не как демо на API, а как часть production-системы.
Внутри книги заявлены три главные вещи:
1️⃣ Фреймворк из 7 шагов для GenAI System Design
Авторы предлагают не начинать сразу с "берем LLM и векторную базу данных", а последовательно пройти путь от требований до деплоя и мониторинга в проде. Это сильно дисциплинирует мышление, потому что в GenAI-задачах легко перепрыгнуть к модной технологии и забыть про реальные ограничения продукта.
2️⃣ 10 практических задач с подробными решениями
Среди кейсов есть следующие: Gmail Smart Compose, Google Translate, ChatGPT-like personal assistant, Image Captioning, Retrieval-Augmented Generation, Realistic Face Generation, High-Resolution Image Synthesis, Text-to-Image Generation, Personalized Headshot Generation и Text-to-Video Generation. Этот набор покрывает разные сценарии и сильно шире, чем просто прикрутить трансформер к чат-боту:)
3️⃣ Много диаграмм и end-to-end разборов
Для System Design это особенно важно. Хороший ответ на интервью - это не только "какую модель выбрать", но и то, как выглядит система вокруг модели: preprocessing, retrieval, prompt builder, inference service, post-processing, safety layer, logging, monitoring, feedback loop. Мне кажется, главная ценность книги в том, что она показывает: "GenAI-система - это не модель в вакууме".
В общем, модель - это конечно ядро, но вокруг него есть данные, права доступа, индексы, промпты, ранжирование, guardrails, UX, стоимость, GPU-инфраструктура, A/B-тесты, метрики качества и эксплуатационные ограничения. И если все это не проектировать осознанно, то на выходе получается не production-система, а красивый прототип с непредсказуемым поведением.
Книга полезна как способ обновить представление о System Design в эпоху AI, ведь раньше мы проектировали в основном детерминированный софт: запрос пришел, сервис обработал, база ответила, результат вернулся. Теперь все чаще приходится проектировать системы с вероятностным поведением: модель может ответить хорошо, средне, неверно, опасно, дорого или слишком медленно. Поэтому архитектура должна включать не только масштабирование и отказоустойчивость, но и evaluation, safety, feedback и постоянный контур улучшения.
В продолжении более подробный разбор фреймворка в 7 шагов от авторов книги.
#SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software
Изучил интересную книгу для подготовки к интервью по System Design, но уже в новой реальности, когда проектировать надо не только базы, очереди, кэши и микросервисы, но и системы вокруг LLM, diffusion models, RAG, мультимодальных моделей и AI-powered продуктов. Это русское издание книги "Generative AI System Design Interview" из экосистемы ByteByteGo. Авторы - Али Аминиан и Хао Шенг. Али Аминиан уже известен по книге про ML System Design Interview, а здесь фокус смещается с классических ML-систем вроде поиска и рекомендаций на генеративный AI: чатботы, генерацию текста, изображений, видео, RAG и персонализированные AI-сценарии.
В обычном System Design Interview кандидат часто рисует распределенную систему: API, балансировщики, базы данных, очереди, кэши, фоновые джобы, мониторинг. В GenAI-интервью все это остается, но появляется еще один слой сложности:
- Какие данные нужны;
- Какую модель выбрать;
- Нужен ли RAG или fine-tuning;
- Как измерять качество генерации;
- Как бороться с hallucinations;
- Как учитывать latency и стоимость инференса;
- Как встроить safety-фильтры;
- Как собирать feedback loop;
- Как мониторить деградацию системы после запуска.
Именно поэтому книга полезна не только ML-инженерам. Она хорошо ложится и на backend engineers, и на архитекторов, и на технических руководителей, которым сейчас приходится проектировать AI-фичи не как демо на API, а как часть production-системы.
Внутри книги заявлены три главные вещи:
1️⃣ Фреймворк из 7 шагов для GenAI System Design
Авторы предлагают не начинать сразу с "берем LLM и векторную базу данных", а последовательно пройти путь от требований до деплоя и мониторинга в проде. Это сильно дисциплинирует мышление, потому что в GenAI-задачах легко перепрыгнуть к модной технологии и забыть про реальные ограничения продукта.
2️⃣ 10 практических задач с подробными решениями
Среди кейсов есть следующие: Gmail Smart Compose, Google Translate, ChatGPT-like personal assistant, Image Captioning, Retrieval-Augmented Generation, Realistic Face Generation, High-Resolution Image Synthesis, Text-to-Image Generation, Personalized Headshot Generation и Text-to-Video Generation. Этот набор покрывает разные сценарии и сильно шире, чем просто прикрутить трансформер к чат-боту:)
3️⃣ Много диаграмм и end-to-end разборов
Для System Design это особенно важно. Хороший ответ на интервью - это не только "какую модель выбрать", но и то, как выглядит система вокруг модели: preprocessing, retrieval, prompt builder, inference service, post-processing, safety layer, logging, monitoring, feedback loop. Мне кажется, главная ценность книги в том, что она показывает: "GenAI-система - это не модель в вакууме".
В общем, модель - это конечно ядро, но вокруг него есть данные, права доступа, индексы, промпты, ранжирование, guardrails, UX, стоимость, GPU-инфраструктура, A/B-тесты, метрики качества и эксплуатационные ограничения. И если все это не проектировать осознанно, то на выходе получается не production-система, а красивый прототип с непредсказуемым поведением.
Книга полезна как способ обновить представление о System Design в эпоху AI, ведь раньше мы проектировали в основном детерминированный софт: запрос пришел, сервис обработал, база ответила, результат вернулся. Теперь все чаще приходится проектировать системы с вероятностным поведением: модель может ответить хорошо, средне, неверно, опасно, дорого или слишком медленно. Поэтому архитектура должна включать не только масштабирование и отказоустойчивость, но и evaluation, safety, feedback и постоянный контур улучшения.
В продолжении более подробный разбор фреймворка в 7 шагов от авторов книги.
#SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software
🔥14❤9👍5👎1
[2/3] System Design. Подготовка к сложному интервью по GenAI (Рубрика #SystemDesign)
Продолжая тему книги, стоит обсуждть фреймворк из 7 шагов, который важен, так как такое интервью легко провалить разными способами, например
- Отвечать как на обычном backend system design интервью и почти не говорить про данные, модели, качество генерации, hallucinations и safety
- Говорить только про LLM, RAG, embeddings и fine-tuning, но забыть, что это все должно работать как production-система: с задержками, стоимостью, мониторингом, контролем доступа, fallback’ами и нормальной эксплуатацией
А хороший фреймворк может помочь не свалиться в эти крайности. И ниже представлены шаги такого фреймворка
1️⃣ Clarifying requirements
Сначала надо понять, что именно мы строим. "Чатбот", "генератор картинок" или "AI-ассистент" - слишком широкие формулировки. Хороший кандидат уточняет: кто пользователь, какой input и output, нужна ли персонализация, нужна ли память, какие языки и модальности поддерживаем, какой latency budget, сколько пользователей, можно ли ошибаться, какие требования к privacy и security, насколько критичны hallucinations. Это похоже на обычный System Design, но с AI-специфичными вопросами: можно ли использовать пользовательские данные, нужен ли RAG, нужен ли fine-tuning, какие safety-ограничения есть на входе и выходе.
2️⃣ Framing the problem as an ML task
Дальше продуктовую задачу надо перевести в ML-формулировку. Например, Gmail Smart Compose - это не просто "помогать писать письма". Это text generation: на входе уже набранная часть письма, на выходе - короткое вероятное продолжение. RAG-система - это не просто «чатбот по документам». Это retrieval-augmented question answering: пользовательский запрос → поиск релевантных chunks → сбор контекста → генерация ответа → проверка и ссылки на источники. На этом шаге важно показать, что вы различаете generation, transformation, retrieval, ranking, summarization, captioning, translation и multimodal tasks.
3️⃣ Data preparation
В GenAI данные - это часть качества системы. Надо обсудить: откуда берутся данные, как их чистить, как удалять персональную информацию, как фильтровать NSFW и токсичный контент, как бороться с bias, как делать чанки документов, как строить embeddings, как версионировать данные и индексы, как соблюдать права доступа.
Для RAG это особенно критично. Если retrieval достал неправильный контекст, то даже хорошая LLM сгенерирует уверенный, но бесполезный ответ.
4️⃣ Model development
Теперь можно обсуждать модель. Но не в формате "возьмем самую большую модель". Для Smart Compose может быть важнее маленькая и быстрая decoder-only Transformer-модель, потому что подсказка должна появляться почти мгновенно. Для Google Translate логичнее encoder-decoder Transformer, потому что это задача преобразования из одного языка в другой. В общем, хороший ответ включает объяснения компромиссов.
5️⃣ Evaluation
Это один из самых важных шагов в этих задачах. В обычных ML-задачах часто можно говорить про accuracy, precision, recall. Но в GenAI все сложнее: у хорошего ответа может не быть единственного ground truth. Поэтому надо разделять: offline оценка, online оценка, оценка людей, продуктовые метрики, системные метрики, safety метрики.
6️⃣ Overall ML system design
Это центральный момент: собрать систему целиком. В этот момент становится видно, что GenAI System Design — это не только ML, но и нормальная инженерия: сервисы, очереди, хранилища, кэширование, права доступа, observability, rollback, A/B-тесты и capacity planning.
7️⃣ Deployment and monitoring
После запуска GenAI-продукт надо постоянно мониторить: latency, token usage, cost per request, GPU utilization, timeout rate, safety filter trigger rate, hallucination signals, user feedback, retrieval quality, drift в данных, деградацию после смены модели или версии промпта, попытки prompt injection и abuse. Именно этот слой отличает production AI-систему от красивого демо.
А в последнем посте мы посмотрим на задачи из книги.
#SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software
Продолжая тему книги, стоит обсуждть фреймворк из 7 шагов, который важен, так как такое интервью легко провалить разными способами, например
- Отвечать как на обычном backend system design интервью и почти не говорить про данные, модели, качество генерации, hallucinations и safety
- Говорить только про LLM, RAG, embeddings и fine-tuning, но забыть, что это все должно работать как production-система: с задержками, стоимостью, мониторингом, контролем доступа, fallback’ами и нормальной эксплуатацией
А хороший фреймворк может помочь не свалиться в эти крайности. И ниже представлены шаги такого фреймворка
1️⃣ Clarifying requirements
Сначала надо понять, что именно мы строим. "Чатбот", "генератор картинок" или "AI-ассистент" - слишком широкие формулировки. Хороший кандидат уточняет: кто пользователь, какой input и output, нужна ли персонализация, нужна ли память, какие языки и модальности поддерживаем, какой latency budget, сколько пользователей, можно ли ошибаться, какие требования к privacy и security, насколько критичны hallucinations. Это похоже на обычный System Design, но с AI-специфичными вопросами: можно ли использовать пользовательские данные, нужен ли RAG, нужен ли fine-tuning, какие safety-ограничения есть на входе и выходе.
2️⃣ Framing the problem as an ML task
Дальше продуктовую задачу надо перевести в ML-формулировку. Например, Gmail Smart Compose - это не просто "помогать писать письма". Это text generation: на входе уже набранная часть письма, на выходе - короткое вероятное продолжение. RAG-система - это не просто «чатбот по документам». Это retrieval-augmented question answering: пользовательский запрос → поиск релевантных chunks → сбор контекста → генерация ответа → проверка и ссылки на источники. На этом шаге важно показать, что вы различаете generation, transformation, retrieval, ranking, summarization, captioning, translation и multimodal tasks.
3️⃣ Data preparation
В GenAI данные - это часть качества системы. Надо обсудить: откуда берутся данные, как их чистить, как удалять персональную информацию, как фильтровать NSFW и токсичный контент, как бороться с bias, как делать чанки документов, как строить embeddings, как версионировать данные и индексы, как соблюдать права доступа.
Для RAG это особенно критично. Если retrieval достал неправильный контекст, то даже хорошая LLM сгенерирует уверенный, но бесполезный ответ.
4️⃣ Model development
Теперь можно обсуждать модель. Но не в формате "возьмем самую большую модель". Для Smart Compose может быть важнее маленькая и быстрая decoder-only Transformer-модель, потому что подсказка должна появляться почти мгновенно. Для Google Translate логичнее encoder-decoder Transformer, потому что это задача преобразования из одного языка в другой. В общем, хороший ответ включает объяснения компромиссов.
5️⃣ Evaluation
Это один из самых важных шагов в этих задачах. В обычных ML-задачах часто можно говорить про accuracy, precision, recall. Но в GenAI все сложнее: у хорошего ответа может не быть единственного ground truth. Поэтому надо разделять: offline оценка, online оценка, оценка людей, продуктовые метрики, системные метрики, safety метрики.
6️⃣ Overall ML system design
Это центральный момент: собрать систему целиком. В этот момент становится видно, что GenAI System Design — это не только ML, но и нормальная инженерия: сервисы, очереди, хранилища, кэширование, права доступа, observability, rollback, A/B-тесты и capacity planning.
7️⃣ Deployment and monitoring
После запуска GenAI-продукт надо постоянно мониторить: latency, token usage, cost per request, GPU utilization, timeout rate, safety filter trigger rate, hallucination signals, user feedback, retrieval quality, drift в данных, деградацию после смены модели или версии промпта, попытки prompt injection и abuse. Именно этот слой отличает production AI-систему от красивого демо.
А в последнем посте мы посмотрим на задачи из книги.
#SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software
👍6❤5🔥2👎1
[3/3] System Design. Подготовка к сложному интервью по GenAI (Рубрика #SystemDesign)
Заканчивая разбор книги (1 и 2), стоит посмотреть 10 задач, что подготовили авторы для тренировок
1️⃣ Gmail Smart Compose - система, которая прямо во время набора письма предлагает продолжение фразы. Здесь важно уложиться в очень маленькую задержку, показывать подсказку только когда модель достаточно уверена, и дополнительно фильтровать неудачные, токсичные или неуместные варианты.
2️⃣ Google Translate - система машинного перевода, которая принимает текст на одном языке и превращает в текст на другом языке. Главные вопросы: как работать с разными языками, как обучаться на многоязычных данных и как измерять качество перевода, если дословный перевод не всегда является лучшим.
3️⃣ ChatGPT-like Personal Assistant - персональный AI-ассистент, который ведет диалог, помнит контекст, может обращаться к внешним инструментам и подстраиваться под пользователя. Здесь особенно важны безопасность, управление памятью, приватность и контроль за тем, что ассистент может делать от имени человека.
4️⃣ Image Captioning - система, которая смотрит на изображение и генерирует его текстовое описание. Это пример мультимодальной задачи: на входе картинка, на выходе текст. Важно не просто "угадать объекты", а описать сцену так, чтобы это было полезно пользователю.
5️⃣ Retrieval-Augmented Generation - система, которая отвечает на вопросы не только из "памяти" модели, а сначала ищет релевантные фрагменты в документах, базе знаний или корпоративном поиске. Главные темы: как разбивать документы на части, как искать близкие по смыслу фрагменты, как заставить модель опираться на найденные источники и как показывать ссылки на них.
6️⃣ Realistic Face Generation - система генерации реалистичных лиц. Здесь важно не только качество картинки, но и риски: смещения в данных, генерация нежелательного контента, возможность злоупотреблений и необходимость защитных ограничений.
7️⃣ High-Resolution Image Synthesis - система генерации или улучшения изображений в высоком разрешении. Главная инженерная сложность в том, что такие операции дорого стоят по вычислениям, поэтому часто приходится строить многошаговый пайплайн: сначала грубая генерация, потом улучшение, детализация и увеличение разрешения.
8️⃣ Text-to-Image Generation - система, которая создает изображение по текстовому описанию. Здесь важно понять, как текстовый запрос превращается в визуальный результат, как управлять стилем и деталями изображения, а также как фильтровать запрещенные или небезопасные запросы и результаты.
9️⃣ Personalized Headshot Generation - система, которая генерирует персонализированный портрет пользователя, например деловую аватарку или фотографию для профиля. Основные сложности: сохранить узнаваемость человека, не нарушить приватность, правильно хранить и удалять пользовательские изображения, а также не допустить злоупотреблений с чужой личностью.
🔟 Text-to-Video Generation - система, которая создает видео по текстовому описанию. Это один из самых сложных классов задач: нужно не только генерировать красивые кадры, но и сохранять связность сцены во времени, движение объектов, стиль, персонажей и при этом управлять очень дорогими и долгими вычислениями.
Эти задачи стоит не просто прочитать, а прорешать как тренировочные интервью - поставить таймер и самому набросать дизайн: требования, ML-формулировку, данные, модель, метрики, архитектуру, deployment и monitoring. А потом уже сравнить с авторским разбором.
#SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software
Заканчивая разбор книги (1 и 2), стоит посмотреть 10 задач, что подготовили авторы для тренировок
1️⃣ Gmail Smart Compose - система, которая прямо во время набора письма предлагает продолжение фразы. Здесь важно уложиться в очень маленькую задержку, показывать подсказку только когда модель достаточно уверена, и дополнительно фильтровать неудачные, токсичные или неуместные варианты.
2️⃣ Google Translate - система машинного перевода, которая принимает текст на одном языке и превращает в текст на другом языке. Главные вопросы: как работать с разными языками, как обучаться на многоязычных данных и как измерять качество перевода, если дословный перевод не всегда является лучшим.
3️⃣ ChatGPT-like Personal Assistant - персональный AI-ассистент, который ведет диалог, помнит контекст, может обращаться к внешним инструментам и подстраиваться под пользователя. Здесь особенно важны безопасность, управление памятью, приватность и контроль за тем, что ассистент может делать от имени человека.
4️⃣ Image Captioning - система, которая смотрит на изображение и генерирует его текстовое описание. Это пример мультимодальной задачи: на входе картинка, на выходе текст. Важно не просто "угадать объекты", а описать сцену так, чтобы это было полезно пользователю.
5️⃣ Retrieval-Augmented Generation - система, которая отвечает на вопросы не только из "памяти" модели, а сначала ищет релевантные фрагменты в документах, базе знаний или корпоративном поиске. Главные темы: как разбивать документы на части, как искать близкие по смыслу фрагменты, как заставить модель опираться на найденные источники и как показывать ссылки на них.
6️⃣ Realistic Face Generation - система генерации реалистичных лиц. Здесь важно не только качество картинки, но и риски: смещения в данных, генерация нежелательного контента, возможность злоупотреблений и необходимость защитных ограничений.
7️⃣ High-Resolution Image Synthesis - система генерации или улучшения изображений в высоком разрешении. Главная инженерная сложность в том, что такие операции дорого стоят по вычислениям, поэтому часто приходится строить многошаговый пайплайн: сначала грубая генерация, потом улучшение, детализация и увеличение разрешения.
8️⃣ Text-to-Image Generation - система, которая создает изображение по текстовому описанию. Здесь важно понять, как текстовый запрос превращается в визуальный результат, как управлять стилем и деталями изображения, а также как фильтровать запрещенные или небезопасные запросы и результаты.
9️⃣ Personalized Headshot Generation - система, которая генерирует персонализированный портрет пользователя, например деловую аватарку или фотографию для профиля. Основные сложности: сохранить узнаваемость человека, не нарушить приватность, правильно хранить и удалять пользовательские изображения, а также не допустить злоупотреблений с чужой личностью.
🔟 Text-to-Video Generation - система, которая создает видео по текстовому описанию. Это один из самых сложных классов задач: нужно не только генерировать красивые кадры, но и сохранять связность сцены во времени, движение объектов, стиль, персонажей и при этом управлять очень дорогими и долгими вычислениями.
Эти задачи стоит не просто прочитать, а прорешать как тренировочные интервью - поставить таймер и самому набросать дизайн: требования, ML-формулировку, данные, модель, метрики, архитектуру, deployment и monitoring. А потом уже сравнить с авторским разбором.
#SystemDesign #AI #GenAI #Architecture #Engineering #ML #Interview #Software
Telegram
Книжный куб
[1/3] System Design. Подготовка к сложному интервью по GenAI (Рубрика #SystemDesign)
Изучил интересную книгу для подготовки к интервью по System Design, но уже в новой реальности, когда проектировать надо не только базы, очереди, кэши и микросервисы, но…
Изучил интересную книгу для подготовки к интервью по System Design, но уже в новой реальности, когда проектировать надо не только базы, очереди, кэши и микросервисы, но…
❤9👍5🔥1
Кадры / The Internship: Google как старая техноутопия и новая реальность AI-агентов (Рубрика #Culture)
Недавно пересмотрели с женой фильм "Кадры" / "The Internship" 2013 года. На поверхности это довольно простая комедия с Винсом Воном и Оуэном Уилсоном: два олдскульных продавца, Билли и Ник, теряют работу, потому что их привычный мир уходит в цифру, а дальше пытаются попасть на стажировку в Google, хотя почти ничего не понимают в современной технологической культуре. У фильма довольно скромные 34% Tomatometer, так что это не киношедевр, но интересный артефакт индустрии.
Главная мысль, которая сейчас смотрится совсем иначе: в 2013 году герои фильма боялись, что их знания устарели и их вытеснила цифровая экономика. Но спасением тогда выглядел BigTech. Google в фильме - это почти карьерный рай: кампус, бесплатная еда, умные люди, красивые офисы, веселые хакатоны, меритократия и шанс начать жизнь заново. А в 2026 году картина стала сложнее. Теперь уже сам BigTech не выглядит спокойной гаванью - сегодня внутри таких компаний тоже идет собственная перестройка: меньше слоев менеджмента, больше AI-инфраструктуры, больше автоматизации и больше ожиданий от каждого инженера.
1️⃣ Устаревают не люди, а способ создания ценности
Билли и Ник в фильме не глупые. Они умеют продавать, договариваться, читать людей, поддерживать команду, вытаскивать слабых участников и превращать группу случайных людей в работающую систему. Их проблема не в отсутствии интеллекта, а в том, что рынок резко поменял интерфейс к ценности. Сейчас похожая история происходит с обычной разработкой. Если ценность инженера сводится к "быстро написать CRUD", "сверстать экран", "поправить тест", то эта часть работы все быстрее уходит к AI-инструментам и агентам. Но это не значит, что инженер становится ненужным. Это значит, что дешевеет конкретный способ создавать результат.
2️⃣ BigTech перестал быть финальной точкой маршрута
В фильме Google выглядит как место, где можно "переизобрести себя" и получить билет в новую экономику. Это очень дух 2010-х: попади в правильную технологическую компанию - и ты снова на стороне будущего. Сейчас эта логика ломается: безопасной является не компания, а способность человека менять собственный уровень абстракции и создавать ценность с использованием AI.
3️⃣ AI-агенты бьют не только по junior-задачам
Есть удобная версия реальности: AI заберет только самые простые задачи, а все сложное останется людям. Частично это правда, но не полностью. Под ударом оказывается любой инженер, senior или middle, если его работа распадается на хорошо делегируемые микрозадачи без сильного ownership вокруг результата.
4️⃣ Суперзвезды - это не обязательно “ML PhD”, а люди с agentic leverage
Кажется, что индустрия теперь ищет только ML/AI-суперзвезд. И это правда: спрос на людей, которые понимают модели, данные, evaluation, inference, GPU-инфраструктуру и production AI, действительно вырос. Но важна и другая категория - инженеры, которые умеют строить и эксплуатировать контуры, где AI-агенты становятся частью production-системы.
5️⃣ Фильм хорошо показывает ценность “не кодовых” навыков, но сегодня этого мало
В "Кадрах" герои выигрывают не потому, что внезапно становятся лучшими программистами. Они выигрывают потому, что умеют делать то, чего не умеют молодые технари вокруг них: собрать группу, вытянуть слабых, договориться, придумать нестандартный ход. Это все до сих пор важно. Более того, в мире AI это становится еще важнее, потому что когда код дешевеет, дороже становятся:
- Постановка задачи;
- Вкус к хорошему решению;
- Коммуникация с бизнесом;
- Понимание пользователя;
- Способность довести дело до результата;
- Ответственность за последствия.
В общем, если подытожить, то теперь набор необходимых знаний и навыков выглядит шире: нужны знания домена, умение проектировать решения, навыки использования AI инструментов, ну и крутой уровень базовых инженерных практик.
#SystemDesign #AI #GenAI #Engineering #Software
Недавно пересмотрели с женой фильм "Кадры" / "The Internship" 2013 года. На поверхности это довольно простая комедия с Винсом Воном и Оуэном Уилсоном: два олдскульных продавца, Билли и Ник, теряют работу, потому что их привычный мир уходит в цифру, а дальше пытаются попасть на стажировку в Google, хотя почти ничего не понимают в современной технологической культуре. У фильма довольно скромные 34% Tomatometer, так что это не киношедевр, но интересный артефакт индустрии.
Главная мысль, которая сейчас смотрится совсем иначе: в 2013 году герои фильма боялись, что их знания устарели и их вытеснила цифровая экономика. Но спасением тогда выглядел BigTech. Google в фильме - это почти карьерный рай: кампус, бесплатная еда, умные люди, красивые офисы, веселые хакатоны, меритократия и шанс начать жизнь заново. А в 2026 году картина стала сложнее. Теперь уже сам BigTech не выглядит спокойной гаванью - сегодня внутри таких компаний тоже идет собственная перестройка: меньше слоев менеджмента, больше AI-инфраструктуры, больше автоматизации и больше ожиданий от каждого инженера.
1️⃣ Устаревают не люди, а способ создания ценности
Билли и Ник в фильме не глупые. Они умеют продавать, договариваться, читать людей, поддерживать команду, вытаскивать слабых участников и превращать группу случайных людей в работающую систему. Их проблема не в отсутствии интеллекта, а в том, что рынок резко поменял интерфейс к ценности. Сейчас похожая история происходит с обычной разработкой. Если ценность инженера сводится к "быстро написать CRUD", "сверстать экран", "поправить тест", то эта часть работы все быстрее уходит к AI-инструментам и агентам. Но это не значит, что инженер становится ненужным. Это значит, что дешевеет конкретный способ создавать результат.
2️⃣ BigTech перестал быть финальной точкой маршрута
В фильме Google выглядит как место, где можно "переизобрести себя" и получить билет в новую экономику. Это очень дух 2010-х: попади в правильную технологическую компанию - и ты снова на стороне будущего. Сейчас эта логика ломается: безопасной является не компания, а способность человека менять собственный уровень абстракции и создавать ценность с использованием AI.
3️⃣ AI-агенты бьют не только по junior-задачам
Есть удобная версия реальности: AI заберет только самые простые задачи, а все сложное останется людям. Частично это правда, но не полностью. Под ударом оказывается любой инженер, senior или middle, если его работа распадается на хорошо делегируемые микрозадачи без сильного ownership вокруг результата.
4️⃣ Суперзвезды - это не обязательно “ML PhD”, а люди с agentic leverage
Кажется, что индустрия теперь ищет только ML/AI-суперзвезд. И это правда: спрос на людей, которые понимают модели, данные, evaluation, inference, GPU-инфраструктуру и production AI, действительно вырос. Но важна и другая категория - инженеры, которые умеют строить и эксплуатировать контуры, где AI-агенты становятся частью production-системы.
5️⃣ Фильм хорошо показывает ценность “не кодовых” навыков, но сегодня этого мало
В "Кадрах" герои выигрывают не потому, что внезапно становятся лучшими программистами. Они выигрывают потому, что умеют делать то, чего не умеют молодые технари вокруг них: собрать группу, вытянуть слабых, договориться, придумать нестандартный ход. Это все до сих пор важно. Более того, в мире AI это становится еще важнее, потому что когда код дешевеет, дороже становятся:
- Постановка задачи;
- Вкус к хорошему решению;
- Коммуникация с бизнесом;
- Понимание пользователя;
- Способность довести дело до результата;
- Ответственность за последствия.
В общем, если подытожить, то теперь набор необходимых знаний и навыков выглядит шире: нужны знания домена, умение проектировать решения, навыки использования AI инструментов, ну и крутой уровень базовых инженерных практик.
#SystemDesign #AI #GenAI #Engineering #Software
Кинопоиск
«Кадры» (The Internship, 2013)
🎬 Винс Вон и Оуэн Уилсон пытаются получить работу в Google. Мотивирующая комедия о том, что возраст — не главное. Смотрите онлайн фильм Кадры на Кинопоиске.
3❤17👍7🔥3