From Writing Code to Managing Agents. Most Engineers Aren't Ready | Stanford University, Mihail Eric (Рубрика #Engineering)

Интересное интервью Mihail Eric, Head of AI at Monaco и лектора Стэнфорда, где он ведёт курс "CS146S: The Modern Software Developer". Mihail Eric интересно рассказывает про то, куда реально двигается разработка софта. Основная мысль про то, что профессия не исчезает, но центр тяжести уходит от ручного написания каждой строчки к оркестрации AI-агентов, декомпозиции задач, проверке результатов и проектированию среды, в которой агентам можно доверять. Собственно, сам курс "CS146S: The Modern Software Developer" как раз про это.

В этом интервью 15-минутном интервью были несколько интересных мыслей

1️⃣ Eric объясняет почему junior-рынок так штормит тремя факторами
- Перегретый найм после 2021 года и последующие сокращения
- Резкий рост числа CS-выпускников
- AI, из-за которого компании всё чаще думают не "кого ещё нанять", а "сколько AI-native инженеров нужно, чтобы закрыть тот же объём работы"

2️⃣ Eric объясняет, а кто такой AI-native engineer
- Это не просто про промпт инженер, а скорее разработчик с нормальной базой в system design, алгоритмах и традиционной разработке
- Этот инженер должен уметь работать с агентскими workflow
По мнению Eric основная ошибка - это попытка сразу запускать много агентов. Но лучше начинать наоборот: сначала один агент на один workflow, потом постепенно добавлять только изолированные задачи и лишь затем масштабировать оркестрацию

3️⃣ Eric рассказывает про дружелюбную для агентов кодовую базу
- Для агента тесты - это не "nice to have" фича, а фактически контракты
- Если тестов мало, README устарел, а одинаковые сущности создаются разными паттернами в разных местах, то агент начинает гадать - и очень быстро начинает плодить ошибки.
В итоге, тексты, документация и единые паттерны базы - это не просто инженерная гигиена, а просто база для AI-native разработки

4️⃣ Eric отмечает, что мульти-агентные workflows больше похожи на менеджмент, чем на классическое программирование
Нужно уметь быстро переключать контекст, держать в голове, чем занят каждый агент, понимать, где он застрял, и мягко возвращать его в правильную траекторию. По сути, сильный AI-native engineer - это уже немного менеджер команды из агентов:)

5️⃣ Eric отмечает важность вкуса продуктового и инженерного
Функциональный продукт и действительно сильный продукт разделяет не только корректность кода, но и желание пройти "последнюю милю": сделать фичу устойчивее, полезнее, глубже, довести UX и robustness. Eric связывает это с постоянным экспериментированием: даже команды, которые строят AI-инструменты, сами всё время переписывают и переизобретают свои workflow.

В общем, автор за 15 минут продал мне свой курс про современную разработку софта, лекции которого уже доступны на Youtube (правда, это не официальная версия, которую я не нашел, а сгенерированная через notebook lm на основе материалов курса)

#Agents #Software #Engineering #Management #DistributedSystems #SystemDesign #AI

[1/2] The State of DevOps Report 2026 от Perforce (Рубрика #DevOps)

Изучил новый "State of DevOps 2026" от Perforce, который фокусировался на вопросе: что на самом деле определяет успех AI в системе поставки ценности - сами AI-инструменты или зрелость инженерной системы. Этот вопрос обусловлен вендорской спецификой, так как Perforce - это вендор Devops стека, поэтому авторы исследовали связь между зрелостью DevOps процессов, глубиной внедрения AI, ролью платформенной инженерии и IDP, а также пробелами в измерениях и экономическим эффектом AI относительно стоимости. Ну и ребята пришли к логичному выводу, что для масштабирования AI нужны зрелые DevOps практики и процессы.

Методология выглядела как опрос 820 респондентов из глобального собщества, которые принимают IT решения, влияют на IT закупки, выбор инфраструктурных и платформеннных инструментов, а также на mission-critical приложения. С учетом такой выборки это скорее менеджерский взгляд на связь зрелости DevOps практик и AI, а не взгляд с позиции инженеров. Забавно, что авторы отфильтровывали из отчета менеджеров, которые не смогли бы объяснить коллегам термин "Agentic AI". А зрелость DevOps процессов авторы определяли операционно: через степень стандартизации delivery, качество работы с инцидентами, а также долю автоматизации деплоев, наличие автоматических rollback. В общем, авторы не претендуют на репрезентативность и выявление причинно-следственных связей, но дают интересную описательную статистику.

В основу исследования легли четыре ключевых вопроса
1) Влияет ли зрелость DevOps на успех AI?
2) Что нужно, чтобы AI масштабировался между командами - локальные инструменты или централизованные системы, IDP (внутренние платформы разрботки) и control planes?
3) Умеют ли компании измерять и аудировать AI, или пока просто "верят", что он помогает?
4) Есть ли экономический эффект, и не съедают ли его cloud/compute затраты?
Собственно, поэтому сам отчет и состоит из четырех частей:)

В следующем посте я расскажу подробнее про полученные авторами результаты по итогам этого опроса

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

[2/2] The State of DevOps Report 2026 от Perforce (Рубрика #DevOps)

Продолжая рассказ про новый отчет "State of DevOps 2026" от Perforce, поделюсь основными результатами, которые представляют менеджерский взгляд на связь зрелости DevOps практик и AI (ребята так подбирали респондентов, чтобы это были в основном менеджеры, что принимают решения по инфраструктурным и платформенным решениям в своих компаниях).

1️⃣ 70% респондентов говорят, что зрелость DevOps заметно повлияла на успех AI
При этом только 38% организаций реально встроили AI глубоко в несколько стадий SDLC, еще 38% используют его часто, но без стандартизации, а 17% остаются на уровне ограниченных пилотов. Разрыв по зрелости огромный: в high-maturity организациях 72% лидеров говорят о deeply embedded AI, в mid - 43%, в low - 18%. В итоге, видно, что для масштабирования AI инициатив важна не покупка AI инструментов, а скорее подготовленная почва в виде зрелых инженерных процессов

2️⃣ AI наследует операционную модель работы, а не чинит ее
В отчете 32% организаций описаны как highly standardized, 35% - mostly standardized, а 34% продолжают жить в частичной или хаотичном деливери. То есть примерно треть рынка по‑прежнему находится в зоне, где результат зависит от конкретной команды. Perforce называет это проблемой вариантивности: пока рабочие процессы, окружения и governance отличаются от команды к команде, AI будет давать столь же неравномерный результат. Отсюда и акцент на control plane: не "еще один инструмент", а шаренные шаблоны, шаренные стандарты, шаренные пайплайны и управляемые окружения.

3️⃣ На рынка уже есть разрыв в уверенности между доверием к AI и реальной интеграцией AI инструментов в процессы
77% респондентов говорят, что доверяют AI outputs, но только 38% действительно глубоко встроили AI в delivery, и лишь 39% имеют полностью автоматизированные данные для аудита. В части про измерения авторы формулируют риск прямо: организации доверяют AI быстрее, чем успевают построить проверяемость, auditability и согласованную измеримость. Это важный антидот против иллюзии, что рост локальной продуктивности в IDE уже означает зрелый AI-native delivery.

4️⃣ Экономический эффект есть, но он не возникает автоматически
74% опрошенных считают, что AI встречается с завышенными ожиданиями. Отдельно Perforce показывает, что ROI сильнее у тех, у кого зрелая система поставки: high-maturity организации на 36% чаще автоматизируют 61%+ деплоев от коммита до прода и на 66% чаще "very effectively" отвечают на продовые инциденты. У low-maturity организаций, наоборот, 78% delivery не стандартизованы а только 19% очень эффективно реагируют на инциденты. Если на пальцах, то без зрелого DevOps AI может ускорить работу, но одновременно увеличить долю переделок, вариативность результатов, время downtime и затраты.

На мой взгляд, отчет Perforce очень хорошо подтверждает базовый тезис из моей статьи "От классического PDLC к AI-native разработке", что AI-native - это не еще один умный инструмент, а перестройка всей системы создания, проверки и поставки изменений. Только я иду еще дальше и размышляю про отдельные роли в этом новом процессе:)

#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign

System-Design.Space (Update) (Рубрика #SystemDEsing)

В последние недели я не останавливался с доработками своего сайта system-design.space. И сегодня я решил поделиться тремя ключевыми изменениями

1) Я поменял дизайн главной страницы, чтобы прямо на ней был блок с онбордингом и описанием всех возможностей доступных на сайте:
- Выбор трека изучения
- Изучения графа знаний
- Доступ на страницу со всеми материалами с поиском и фильтрацией по ним
Надеюсь, что теперь сайт станет понятнее и удобнее для пользователей, а то я посмотрел ряд сессий из Яндекс Метрики, где пользователи попадали на сайт и как будто не могли понять а что на нем есть и дальше просто уходили

2) Теперь в каждой главе в начале есть блок, в котором рассказывается о чем глава, почему это полезно для проектирования систем, а также как эти знания можно использовать на интервью - это моя попытка объяснить почему главу стоит прочитать. Если вы по описанию видите, что глава вам не особо полезна или интересна, то сразу можно пролистнуть на следующую

3) Я сам устал от артефактов в мобильной верстке, поэтому мы с OpenAI Codex написали скрипты для e2e тестов layouts в десктопном и мобильном режиме и поправили 90+ проблемных глав. Теперь на мобилке должно быть гораздо приятнее изучать этот сайт.

Было еще какое-то количество небольших изменений, но эти показались мне достойными упоминания.

#SystemDesign #Architecture #Software #DistributedSystems #UX #Interview

The programming language after Kotlin – with the creator of Kotlin (Рубрика #Engineering)

Очередной интересный выпуск "The Pragmatic Engineer" на этот раз с Андреем Бреславом, создателем Kotlin и основателем CodeSpeak, в котором Гергели Орош обсуждает с Андреем как появляются и приходят к успеху инженерные платформы и языки - через правильное время для появления, компромиссы, важность инструментария, совместимость с экосистемой и ясное понимание, что должен делать человек, а что - машина.

Если кратко описать содержимое, то ключевые вопросы и ответы звучат так
1. Почему Kotlin вообще появился
2. Как принимаются языковые компромиссы
3. Почему Java interoperability стала не просто технической деталью, а стратегией успеха Kotlin
4. Как Android неожиданно стал важным ускорителем для Kotlin
5. Что сейчас происходит в рзаработке во время LLM эры

Основные инсайты:
1. Лучшие инженерные решения побеждают не из-за "красоты", а потому что попадают в реальную боль рынка. Kotlin выстрелил не в вакууме: он появился в момент, когда Java тормозила, а разработчикам нужен был более удобный язык без разрыва с существующей экосистемой.
2. Tooling важнее, чем многие думают. Первая версия Kotlin была не компилятором, а IDE-плагином. Сначала язык сделали демонстрируемым и удобным в среде разработчика, а уже потом дотягивали execution path. Это хороший урок для любых platform teams и внутренних developer tools.
3. Дизайн платформы - это управление необратимостью. В Kotlin есть красивые решения вроде smart casts, за которыми скрывается сложная логика компилятора, а есть и сожаления вроде отказа от ternary operator, который позже уже нельзя было аккуратно вернуть. Для техлидов это напоминание: ранние API- и platform-решения цементируются быстрее, чем кажется.
4. Совместимость - это не компромисс второго сорта, а стратегия дистрибуции. Ставка на двустороннюю совместимость с Java и готовность работать в существующих ограничениях экосистемы оказались важнее, чем попытка сделать идеальный "язык с нуля". Android-поворот только усилил этот эффект
5. В эпоху LLM ценность инженера смещается выше по стеку абстракций: от написания каждой строки к описанию intent, ограничений, тестов и гейтов качества. CodeSpeak строится вокруг идеи "поддерживать спецификации, а не код", а сам Бреслав отдельно подчеркивает, что работа с AI coding tools - это навык, которому можно учиться. Он также ожидает новый виток специализированных, agent-first IDE.

В общем, это был интересный подкаст, который только краем задевал тему AI, что теперь редкость в моем плейлисте:)

#SystemDesign #Engineering #Leadership #Architecture #AI #Software #DevEx

CTO 2026: от главного по технологиям к архитектору AI-native компании (Рубрика #Leadership)

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

Ну и напоследок я размышляю о том, а куда CTO стоит вести компанию в 2026 году, чтобы AI стал не модным слоем поверх процессов, а реальным рычагом роста и конкурентного преимущества.

#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity

[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

[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

Управление 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

[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