Почти интеллектуальные системы» (Smart (enough) systems) (Рубрика #Processes)
Нашел у себя на полке книгу про интеллектуальные системы, что вышла почти 20 лет назад. Когда-то давно я ее читал и в ней было много умных слов. А сейчас я ее открыл и понял, что если половину терминов оттуда заменять на модные сейчас слова типа "GenAI", "мультиагентные систем", "RAG" или "context engineering", то текст будет выглядеть как свежий архитектурный гайд по построению интеллектуальных систем. Дальше я решил понять, а что за авторы написали этот труд и оказалось, что там два автора
- Джеймс Тейлор - один из главных евангелистов decision management: работал в Fair Isaac (FICO), где развивал подход Enterprise Decision Management, а позже стал CEO Decision Management Solutions. Он много лет продвигает идею «делайте решения явными и управляемыми».
- Нил Рэйден - легенда BI/analytics: основатель Hired Brains, практик и аналитик, который умел объяснять, почему «данные есть, инсайты есть, а бизнес всё равно принимает решения “на глазок”».
Книга была хороша в свое время, так как в середине 2000‑х компании уже купили ERP/BPM/BI, построили витрины и дашборды… и внезапно обнаружили, что:
- Процессы автоматизировали, а решения внутри процессов - нет
- Аналитика живёт в презентациях и Excel, а не в runtime
- Правила размазаны по коду/табличкам/головам людей и меняются больно
Тейлор и Рэйден попали в нерв: они предложили смотреть на «решение» как на отдельный объект инженерии - как на сервис/компонент, который можно проектировать, тестировать, версионировать, мониторить и улучшать. Не «магический AI», а честная промышленная автоматизация скрытых решений.
Почему и сейчас книга актуальна - потому что многие используют buzzwords для описания желаемого результата вместо того, чтобы описать что именно они хотят. Условно "а тут у нас GenAI сделает все по красоте" или "наша multi-agent система выполнит эту работу сама" или просто "а тут справится AI". Для тех, кто немного понимает в технике такой подход кажется карго-культом. И тут полезно вспомнить про то, о чем рассказывала эта старая книга, а именно про то, что обычно болит в любой интеллектуальной системе:
- Где в продукте спрятаны решения и кто за них отвечает;
- Как отделять decision logic от process orchestration;
- Как сочетать “правила” и “модели” без религиозных войн;
- Как измерять качество решений (а не количество токенов);
- Как обеспечивать согласованность между каналами и командами;
- Как менять логику быстро, но безопасно (управление изменениями, контроль, обратная связь).
Когда читал эту книгу, то составил для себя минисловарик терминов из 2007 года и как они маппятся на термины из 2026 года
- Business rules engine → guardrails / policy engine / “промпт‑конституция”
- Predictive analytics model → ML‑модель / LLM‑модель / routing‑модель
- Decision service → AI‑оркестратор / агент с тулзами / микросервис решения
- Data & analytics → feature store + telemetry + (да‑да) RAG/векторная база
- Adaptive control → online‑эксперименты, bandits, self‑improving пайплайн
- “Make decisions explicit” → «вынесите это из кода/голов в явный артефакт + evals»
Забавно, что в 2007 году авторы специально добавили “(enough)” в название, чтобы отстроиться от тогдашнего "настоящего AI" - мол, нам не нужна эзотерика, нам нужна практическая автоматизация решений. В 2026 мы делаем наоборот: берём те же идеи, добавляем GPU, векторную БД и называем это GenAI.
Итого: технологии крутятся по кругу, а хорошая инженерия - нет. Если вы строите AI‑системы, то вам всё равно придётся:
- Делать решения явными
- Измерять их эффект
- Управлять изменениями
- Обеспечивать контроль и обратную связь
Просто вместо правил/скорингов иногда будет промпт/LLM. 🙂
#AI #Engineering #Software #Management #Leadership #Processes #LLM #ML #Architecture
Нашел у себя на полке книгу про интеллектуальные системы, что вышла почти 20 лет назад. Когда-то давно я ее читал и в ней было много умных слов. А сейчас я ее открыл и понял, что если половину терминов оттуда заменять на модные сейчас слова типа "GenAI", "мультиагентные систем", "RAG" или "context engineering", то текст будет выглядеть как свежий архитектурный гайд по построению интеллектуальных систем. Дальше я решил понять, а что за авторы написали этот труд и оказалось, что там два автора
- Джеймс Тейлор - один из главных евангелистов decision management: работал в Fair Isaac (FICO), где развивал подход Enterprise Decision Management, а позже стал CEO Decision Management Solutions. Он много лет продвигает идею «делайте решения явными и управляемыми».
- Нил Рэйден - легенда BI/analytics: основатель Hired Brains, практик и аналитик, который умел объяснять, почему «данные есть, инсайты есть, а бизнес всё равно принимает решения “на глазок”».
Книга была хороша в свое время, так как в середине 2000‑х компании уже купили ERP/BPM/BI, построили витрины и дашборды… и внезапно обнаружили, что:
- Процессы автоматизировали, а решения внутри процессов - нет
- Аналитика живёт в презентациях и Excel, а не в runtime
- Правила размазаны по коду/табличкам/головам людей и меняются больно
Тейлор и Рэйден попали в нерв: они предложили смотреть на «решение» как на отдельный объект инженерии - как на сервис/компонент, который можно проектировать, тестировать, версионировать, мониторить и улучшать. Не «магический AI», а честная промышленная автоматизация скрытых решений.
Почему и сейчас книга актуальна - потому что многие используют buzzwords для описания желаемого результата вместо того, чтобы описать что именно они хотят. Условно "а тут у нас GenAI сделает все по красоте" или "наша multi-agent система выполнит эту работу сама" или просто "а тут справится AI". Для тех, кто немного понимает в технике такой подход кажется карго-культом. И тут полезно вспомнить про то, о чем рассказывала эта старая книга, а именно про то, что обычно болит в любой интеллектуальной системе:
- Где в продукте спрятаны решения и кто за них отвечает;
- Как отделять decision logic от process orchestration;
- Как сочетать “правила” и “модели” без религиозных войн;
- Как измерять качество решений (а не количество токенов);
- Как обеспечивать согласованность между каналами и командами;
- Как менять логику быстро, но безопасно (управление изменениями, контроль, обратная связь).
Когда читал эту книгу, то составил для себя минисловарик терминов из 2007 года и как они маппятся на термины из 2026 года
- Business rules engine → guardrails / policy engine / “промпт‑конституция”
- Predictive analytics model → ML‑модель / LLM‑модель / routing‑модель
- Decision service → AI‑оркестратор / агент с тулзами / микросервис решения
- Data & analytics → feature store + telemetry + (да‑да) RAG/векторная база
- Adaptive control → online‑эксперименты, bandits, self‑improving пайплайн
- “Make decisions explicit” → «вынесите это из кода/голов в явный артефакт + evals»
Забавно, что в 2007 году авторы специально добавили “(enough)” в название, чтобы отстроиться от тогдашнего "настоящего AI" - мол, нам не нужна эзотерика, нам нужна практическая автоматизация решений. В 2026 мы делаем наоборот: берём те же идеи, добавляем GPU, векторную БД и называем это GenAI.
Итого: технологии крутятся по кругу, а хорошая инженерия - нет. Если вы строите AI‑системы, то вам всё равно придётся:
- Делать решения явными
- Измерять их эффект
- Управлять изменениями
- Обеспечивать контроль и обратную связь
Просто вместо правил/скорингов иногда будет промпт/LLM. 🙂
#AI #Engineering #Software #Management #Leadership #Processes #LLM #ML #Architecture
1🔥13⚡3❤3
T-Sync Conf и итоги исследования AI4SDLC 2025 от Т-Банка (Рубрика #Engineering)
Сегодня я проведу весь день на конференции T-Sync, где нет докладов, а больше дискуссий и зон для общения. Собственно, у меня будет такая зона на втором этаже, где мы сможем поговрить про исследование AI4SDLC, которое мы стартанули в прошлом году опросом сообщества. Само исследование доступно на сайте ai4sdlc.tbank.ru при клике на вкладку "Исследование". Оно состоит из двух частей:
1️⃣ Раздел с мета-исследованием 2023–2025, где мы взяли порядка 50 отдельных исследований за последние годы и посмотрели на их результаты. Особенно интересно было смотреть на тренды серийных исследований, что проводятся ежегодно - по ним видно, как менялось отношение к AI в среде разработки, проникновение AI в разные сценарии, оценки его эффектов и так далее. Среди таких серийных исследований были исследования от: DORA, GitHub, Stack Overflow, JetBrains, Atlassian, McKinsey, Яков и Партнёры / Yandex, Express42, МФТИ. На сайте есть список серий, где можно посмотреть основные тренды каждой серии. Также есть таймлайн со всеми учтенными исследованиями + можно изучить краткое саммари по каждому из них
2️⃣ Раздел с результатами опроса, который мы проводили в конце прошлого года. Опрос получился объемным и я хотел бы поблагодарить всех поучавствовавших в нем. По результатам получилось примерно следующее: начали заполнять опрос порядка 1к человек и хорошо, что мы вопросы про использование и влияние AI вынесли в самое начало, так как до конца опроса дошли не все:) Если говорить, про профиль респондентов, то он получился такой:
- 50% разработчики, 17% технические руководители, 7% топ-менеджеры, 6% qa-инженеры, 4% AI/ML инженеры и так далее
- 24% работают в крупных компаниях (1к - 10к), 23% в очень крупных (10к+ сотрудников), 18% в средних (100 - 500 сотрудников), 16% в маленьких (10-100)
- основные представленные отрасли: финансы - 25%, технологии - 20%, розничная торговля и e-com - 15%, телеком - 7%, образование - 5%
- основные приложения/сервисы, над которыми работают респонденты распределились довольно равномерно: внутреннее/внешнее для пользователей - 45% vs 37% и b2c vs b2b - 34% vs 41%
Если говорить про executive summary результатов опроса, то они такие
- AI для генерации / автодополнения кода используют "часто/всегда" 58%; для code review 24%; для модернизации legacy 18% (при 42% "никогда").
- Производительность выросла у 64% (18% "значительно"); способность писать код улучшилась у 37%.
- Качество кода: улучшение 32%, ухудшение 14%, без изменений 42%.
- Доверие к AI-коду низкое: 49% не доверяют, 11% доверяют (остальные — нейтрально).
- Роль AI внутри компании выросла у 54%; прозрачность планов внедрения ощущают 50%, не ощущают 21%.
- "Системная готовность": commit→prod у заметной части измеряется неделями/месяцами; документация как источник правды работает плохо (около 39–42% не опираются на нее в критичных ситуациях).
И эти результаты хорошо откликаются в результатах мета-исследования
- Охват AI приближается к "почти у всех" (например, в сводках DORA к 2025 — около 90%); при этом личный эффект обычно сильнее командного.
- Узкие места переезжают в интеграцию, тестирование, ревью, релизы, коммуникации; в исследованиях регулярно всплывает тезис, что кодинг - лишь часть времени инженера (и что организационные барьеры съедают ощутимую долю недели).
- Качество и доверие - центральная проблема зрелости: "almost right" ответы создают новый долг проверки и дебага.
- Экспериментальные данные показывают: на сложных задачах эффект может быть нулевым или отрицательным; AI - усилитель системы, а не замена инженерии.
- Без guardrails (тесты, quality gates, small batch, ревью, наблюдаемость) "ускорение" легко превращается в "ускорение хаоса".
В общем, если вас интересует эта тема, то приходите на стенд и я подробнее расскажу про всю эту машинерию и отвечу на дополнительные вопросы.
#AI #RnD #Software #Engineering #Management #Leadership #Metrics #Processes #Productivity
Сегодня я проведу весь день на конференции T-Sync, где нет докладов, а больше дискуссий и зон для общения. Собственно, у меня будет такая зона на втором этаже, где мы сможем поговрить про исследование AI4SDLC, которое мы стартанули в прошлом году опросом сообщества. Само исследование доступно на сайте ai4sdlc.tbank.ru при клике на вкладку "Исследование". Оно состоит из двух частей:
1️⃣ Раздел с мета-исследованием 2023–2025, где мы взяли порядка 50 отдельных исследований за последние годы и посмотрели на их результаты. Особенно интересно было смотреть на тренды серийных исследований, что проводятся ежегодно - по ним видно, как менялось отношение к AI в среде разработки, проникновение AI в разные сценарии, оценки его эффектов и так далее. Среди таких серийных исследований были исследования от: DORA, GitHub, Stack Overflow, JetBrains, Atlassian, McKinsey, Яков и Партнёры / Yandex, Express42, МФТИ. На сайте есть список серий, где можно посмотреть основные тренды каждой серии. Также есть таймлайн со всеми учтенными исследованиями + можно изучить краткое саммари по каждому из них
2️⃣ Раздел с результатами опроса, который мы проводили в конце прошлого года. Опрос получился объемным и я хотел бы поблагодарить всех поучавствовавших в нем. По результатам получилось примерно следующее: начали заполнять опрос порядка 1к человек и хорошо, что мы вопросы про использование и влияние AI вынесли в самое начало, так как до конца опроса дошли не все:) Если говорить, про профиль респондентов, то он получился такой:
- 50% разработчики, 17% технические руководители, 7% топ-менеджеры, 6% qa-инженеры, 4% AI/ML инженеры и так далее
- 24% работают в крупных компаниях (1к - 10к), 23% в очень крупных (10к+ сотрудников), 18% в средних (100 - 500 сотрудников), 16% в маленьких (10-100)
- основные представленные отрасли: финансы - 25%, технологии - 20%, розничная торговля и e-com - 15%, телеком - 7%, образование - 5%
- основные приложения/сервисы, над которыми работают респонденты распределились довольно равномерно: внутреннее/внешнее для пользователей - 45% vs 37% и b2c vs b2b - 34% vs 41%
Если говорить про executive summary результатов опроса, то они такие
- AI для генерации / автодополнения кода используют "часто/всегда" 58%; для code review 24%; для модернизации legacy 18% (при 42% "никогда").
- Производительность выросла у 64% (18% "значительно"); способность писать код улучшилась у 37%.
- Качество кода: улучшение 32%, ухудшение 14%, без изменений 42%.
- Доверие к AI-коду низкое: 49% не доверяют, 11% доверяют (остальные — нейтрально).
- Роль AI внутри компании выросла у 54%; прозрачность планов внедрения ощущают 50%, не ощущают 21%.
- "Системная готовность": commit→prod у заметной части измеряется неделями/месяцами; документация как источник правды работает плохо (около 39–42% не опираются на нее в критичных ситуациях).
И эти результаты хорошо откликаются в результатах мета-исследования
- Охват AI приближается к "почти у всех" (например, в сводках DORA к 2025 — около 90%); при этом личный эффект обычно сильнее командного.
- Узкие места переезжают в интеграцию, тестирование, ревью, релизы, коммуникации; в исследованиях регулярно всплывает тезис, что кодинг - лишь часть времени инженера (и что организационные барьеры съедают ощутимую долю недели).
- Качество и доверие - центральная проблема зрелости: "almost right" ответы создают новый долг проверки и дебага.
- Экспериментальные данные показывают: на сложных задачах эффект может быть нулевым или отрицательным; AI - усилитель системы, а не замена инженерии.
- Без guardrails (тесты, quality gates, small batch, ревью, наблюдаемость) "ускорение" легко превращается в "ускорение хаоса".
В общем, если вас интересует эта тема, то приходите на стенд и я подробнее расскажу про всю эту машинерию и отвечу на дополнительные вопросы.
#AI #RnD #Software #Engineering #Management #Leadership #Metrics #Processes #Productivity
Т-Банк
AI‑решения для разработчиков
❤11🔥5⚡3
Масштабная конференция получилась:) С моего второго этажа отлично видны все остальные стенды - я решил отдохнуть немного, так как чуток осип полтора часа рассказыаать про исследование. А мне еще через полтора часа вести инженерную дискуссию про влияние AI на разработку:)
1🔥32❤9⚡5👍3
The history of C# and TypeScript with Anders Hejlsberg | GitHub (Рубрика #Software)
Интересное интервью Андерса Хейлсберга, создателя C#, Delphi, Turbo Pascal и ведущего архитектора TypeScript, которое он дал GitHub. Андреас разбирает, как создавались C# и TypeScript и какие компромиссы стояли за решениями и какие принципы помогают языкам и командам "жить долго".
Из получасовго интервью можно почерпнуть много интересного
1️⃣ Быстрый фидбек важнее почти всего
Короткий цикл «написал → сразу понял/проверил» определяет скорость и качество. Поэтому ценность TypeScript - не только в типах, но и в инструментах: подсказки, проверка, рефакторинг, быстрый компилятор.
2️⃣Масштаб требует жертвовать личным идеалом
Когда пользователей и сценариев много, побеждает прагматика: язык успешен, если вписывается в реальную работу команд, а не только в учебник.
3️⃣ Эволюция сильнее революции
TypeScript вырос как надстройка над JavaScript: улучшает поддерживаемость больших проектов, не заставляя «сжигать мосты» и менять экосистему.
4️⃣ Прозрачность ускоряет open source
Публичные PR/issue и обсуждения переводят приоритеты от "внутренних" к реальным потребностям, а решения становятся объяснимыми и проверяемыми.
5️⃣ Иногда нужен рывок в основании без ломки внешнего контракта
Переписывание критического компонента ради производительности имеет смысл, если пользователь не платит ценой совместимости.
6️⃣ Эпоха AI смещает роль инженера
Всё больше кода генерируется, а ценность инструментов - в точности: типы, проверки, тесты и рефакторинг как ограждения от правдоподобных ошибок.
7️⃣ "Память проекта" - это актив
История обсуждений и решений (почему сделали так, а не иначе) снижает повторение ошибок и облегчает онбординг.
Если эти lessons learned превратить в какие-то выводы, то они могу быть такими
Для инженеров
- Инвестируйте в быстрый цикл: локальные проверки, быстрые тесты, линтеры/типы, удобные IDE-инструменты.
- Пишите для "коллективного владения": читаемость, предсказуемость, простые правила важнее личной элегантности.
- Учитесь по контексту решений: обсуждения в issue/PR часто дают больше, чем абстрактные «best practices».
- При работе с AI-кодом усиливайте страховку: типизация + статанализ + тесты, иначе вы просто быстрее генерируете долг.
Для технических руководителей
- Ставьте скорость обратной связи в KPI инженерной системы: CI, тесты, статанализ, быстрые сборки. Медленный фидбек рождает процессы-«костыли».
- Держите баланс интересов: стандарты и совместимость важнее вкуса отдельных сильных инженеров.
- Внедряйте изменения через миграции и совместимость: постепенное улучшение обычно дешевле и надёжнее тотальной замены.
- Стройте институциональную память: ADR/решения, ссылки на обсуждения, понятные причины компромиссов - это снижает риски при росте и текучести.
В общем, долгоживущие технологии и команды выигрывают, когда обеспечивают быстрый фидбек, принимают прагматичные компромиссы, эволюционируют с обратной совместимостью, а также ведут прозрачную историю решений.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD
Интересное интервью Андерса Хейлсберга, создателя C#, Delphi, Turbo Pascal и ведущего архитектора TypeScript, которое он дал GitHub. Андреас разбирает, как создавались C# и TypeScript и какие компромиссы стояли за решениями и какие принципы помогают языкам и командам "жить долго".
Из получасовго интервью можно почерпнуть много интересного
1️⃣ Быстрый фидбек важнее почти всего
Короткий цикл «написал → сразу понял/проверил» определяет скорость и качество. Поэтому ценность TypeScript - не только в типах, но и в инструментах: подсказки, проверка, рефакторинг, быстрый компилятор.
2️⃣Масштаб требует жертвовать личным идеалом
Когда пользователей и сценариев много, побеждает прагматика: язык успешен, если вписывается в реальную работу команд, а не только в учебник.
3️⃣ Эволюция сильнее революции
TypeScript вырос как надстройка над JavaScript: улучшает поддерживаемость больших проектов, не заставляя «сжигать мосты» и менять экосистему.
4️⃣ Прозрачность ускоряет open source
Публичные PR/issue и обсуждения переводят приоритеты от "внутренних" к реальным потребностям, а решения становятся объяснимыми и проверяемыми.
5️⃣ Иногда нужен рывок в основании без ломки внешнего контракта
Переписывание критического компонента ради производительности имеет смысл, если пользователь не платит ценой совместимости.
6️⃣ Эпоха AI смещает роль инженера
Всё больше кода генерируется, а ценность инструментов - в точности: типы, проверки, тесты и рефакторинг как ограждения от правдоподобных ошибок.
7️⃣ "Память проекта" - это актив
История обсуждений и решений (почему сделали так, а не иначе) снижает повторение ошибок и облегчает онбординг.
Если эти lessons learned превратить в какие-то выводы, то они могу быть такими
Для инженеров
- Инвестируйте в быстрый цикл: локальные проверки, быстрые тесты, линтеры/типы, удобные IDE-инструменты.
- Пишите для "коллективного владения": читаемость, предсказуемость, простые правила важнее личной элегантности.
- Учитесь по контексту решений: обсуждения в issue/PR часто дают больше, чем абстрактные «best practices».
- При работе с AI-кодом усиливайте страховку: типизация + статанализ + тесты, иначе вы просто быстрее генерируете долг.
Для технических руководителей
- Ставьте скорость обратной связи в KPI инженерной системы: CI, тесты, статанализ, быстрые сборки. Медленный фидбек рождает процессы-«костыли».
- Держите баланс интересов: стандарты и совместимость важнее вкуса отдельных сильных инженеров.
- Внедряйте изменения через миграции и совместимость: постепенное улучшение обычно дешевле и надёжнее тотальной замены.
- Стройте институциональную память: ADR/решения, ссылки на обсуждения, понятные причины компромиссов - это снижает риски при росте и текучести.
В общем, долгоживущие технологии и команды выигрывают, когда обеспечивают быстрый фидбек, принимают прагматичные компромиссы, эволюционируют с обратной совместимостью, а также ведут прозрачную историю решений.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD
YouTube
The history of C# and TypeScript with Anders Hejlsberg | GitHub
Anders Hejlsberg is one of the most influential language designers of our time, having created Turbo Pascal, Delphi, C#, and TypeScript. In this interview, he discusses his 40-year career, the early days of open source at Microsoft, and the decision to move…
❤9🔥5⚡1
[1/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)
Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё больше опирается на AI-агентов, которые пишут код, пока люди задают им цели и контролируют результат. Они приводят статистику, что разработчики Anthropic используют AI в 60% задач, хотя полностью доверяют ему лишь 0–20% работы (это из их декабрьской статьи "How AI is transforming work at Anthropic", о которой я уже рассказывал). В новом документе они приводят кейсы и других компаний, который смогли добиться значимых результатов, но все-таки фокус на 8 тенденциях, что сгруппированы в три категории: foundation trends, capability trends, impact trends. Ну и ниже я расскажу про каждый из трендов, а также поделюсь мыслями, а что делать с ними инженерам и руководителям
1️⃣ Foundation trends: The tectonic shift
Trend 1: The software development lifecycle changes dramatically
SDLC остаётся, но цикл сжимается: агент пишет/дебажит/документирует, тесты и мониторинг быстрее замыкают фидбек (недели → часы).
- Инженерам стоит начать прокачивать «оркестрацию» (декомпозиция, постановка задач агенту, критерии приёмки, быстрый ревью).
• CTO стоит пересобрать процесс и метрики (меньше “время на задачу”, больше “качество+output”), и реально использовать “онбординг за часы” для динамического перераспределения людей по продуктам/проектам
2️⃣ Capability trends: What agents can do
Trend 2: Single agents evolve into coordinated teams
Один агент → команда агентов с ролями + оркестратор. Это про параллельную работу и синхронизацию в VCS. Пример из отчёта: multi-agent оркестрация дала Fountain 50% быстрее screening и сократила срок укомплектования нового центра до <72 часов.
- Инженерам надо научиться резать задачи так, чтобы их можно было делать параллельно (и собирать через PR/чеки).
- CTO стоит внедрять паттерны multi-agent (роли, протоколы, правила мержа/ревью для “агентских” изменений).
Trend 3: Long-running agents build complete systems
Агенты работают «долго»: часы → дни/недели. Могут тащить фичу/подсистему целиком, закрывать техдолг, делать “невыгодные руками” улучшения. Пример: Rakuten прогнали Claude Code по задаче в vLLM (12,5 млн строк) - 7 часов автономной работы и 99,9% точности.
- Инженерам пора начать мыслить чекпоинтами (контракты, тесты, инварианты) и строить ограждения, чтобы агент не «уехал».
- CTO стоит подготовить среду для длинных прогонов (sandbox, CI, лимиты, наблюдаемость) и выделить задачи “под агента” (миграции, рефакторинги, чистка бэклога).
Trend 4: Human oversight scales through intelligent collaboration
Ключ в том, чтобы масштабировать контроль. Агенты учатся звать человека, а не молча “дожимать”; AI проверяет AI (security/архитектура/качество), человек смотрит только «что важно».
- Инженерам надо собирать пайплайн “генерация → автопроверки → человек”.
- CTO стоит формализовать уровни риска и эскалации (что агент может сам, что только через человека), инвестировать в автоматизированный ревью/тестирование.
Trend 5: Agentic coding expands to new surfaces and users
Агентный кодинг выходит за IDE: больше языков (включая legacy типа COBOL/Fortran), больше ролей (ops, security, design, DS), больше интерфейсов для не-разработчиков.
- Инженерам пора готовиться к "коду от доменных экспертов" - нужны шаблоны, guardrails, API/платформа, чтобы это было безопасно. Тут можно вспомнить про условный Lovable и приложения, что продакты сгенерировали через него
- CTO надо сознательно открывать агентные инструменты другим отделам, но через песочницы, права доступа и наблюдаемость.
В продолжении я расскажу про последние три тренда из этого интересного отчета.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё больше опирается на AI-агентов, которые пишут код, пока люди задают им цели и контролируют результат. Они приводят статистику, что разработчики Anthropic используют AI в 60% задач, хотя полностью доверяют ему лишь 0–20% работы (это из их декабрьской статьи "How AI is transforming work at Anthropic", о которой я уже рассказывал). В новом документе они приводят кейсы и других компаний, который смогли добиться значимых результатов, но все-таки фокус на 8 тенденциях, что сгруппированы в три категории: foundation trends, capability trends, impact trends. Ну и ниже я расскажу про каждый из трендов, а также поделюсь мыслями, а что делать с ними инженерам и руководителям
1️⃣ Foundation trends: The tectonic shift
Trend 1: The software development lifecycle changes dramatically
SDLC остаётся, но цикл сжимается: агент пишет/дебажит/документирует, тесты и мониторинг быстрее замыкают фидбек (недели → часы).
- Инженерам стоит начать прокачивать «оркестрацию» (декомпозиция, постановка задач агенту, критерии приёмки, быстрый ревью).
• CTO стоит пересобрать процесс и метрики (меньше “время на задачу”, больше “качество+output”), и реально использовать “онбординг за часы” для динамического перераспределения людей по продуктам/проектам
2️⃣ Capability trends: What agents can do
Trend 2: Single agents evolve into coordinated teams
Один агент → команда агентов с ролями + оркестратор. Это про параллельную работу и синхронизацию в VCS. Пример из отчёта: multi-agent оркестрация дала Fountain 50% быстрее screening и сократила срок укомплектования нового центра до <72 часов.
- Инженерам надо научиться резать задачи так, чтобы их можно было делать параллельно (и собирать через PR/чеки).
- CTO стоит внедрять паттерны multi-agent (роли, протоколы, правила мержа/ревью для “агентских” изменений).
Trend 3: Long-running agents build complete systems
Агенты работают «долго»: часы → дни/недели. Могут тащить фичу/подсистему целиком, закрывать техдолг, делать “невыгодные руками” улучшения. Пример: Rakuten прогнали Claude Code по задаче в vLLM (12,5 млн строк) - 7 часов автономной работы и 99,9% точности.
- Инженерам пора начать мыслить чекпоинтами (контракты, тесты, инварианты) и строить ограждения, чтобы агент не «уехал».
- CTO стоит подготовить среду для длинных прогонов (sandbox, CI, лимиты, наблюдаемость) и выделить задачи “под агента” (миграции, рефакторинги, чистка бэклога).
Trend 4: Human oversight scales through intelligent collaboration
Ключ в том, чтобы масштабировать контроль. Агенты учатся звать человека, а не молча “дожимать”; AI проверяет AI (security/архитектура/качество), человек смотрит только «что важно».
- Инженерам надо собирать пайплайн “генерация → автопроверки → человек”.
- CTO стоит формализовать уровни риска и эскалации (что агент может сам, что только через человека), инвестировать в автоматизированный ревью/тестирование.
Trend 5: Agentic coding expands to new surfaces and users
Агентный кодинг выходит за IDE: больше языков (включая legacy типа COBOL/Fortran), больше ролей (ops, security, design, DS), больше интерфейсов для не-разработчиков.
- Инженерам пора готовиться к "коду от доменных экспертов" - нужны шаблоны, guardrails, API/платформа, чтобы это было безопасно. Тут можно вспомнить про условный Lovable и приложения, что продакты сгенерировали через него
- CTO надо сознательно открывать агентные инструменты другим отделам, но через песочницы, права доступа и наблюдаемость.
В продолжении я расскажу про последние три тренда из этого интересного отчета.
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
1👍12❤6🔥3
[2/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)
В этом посте мы закончим разбирать короткий trend-report Anthropic, который задает фокус того, что стоит делать в 2026 году нам как инженерам и руководителям, чтобы не отстать от стремительно меняющейся индустрии разработки софта.
3️⃣ Impact trends: What agents may change in 2026
Trend 6: Productivity gains reshape software development economics
Эффект - не только "быстрее", но "больше": растёт объём shipped-результата, появляется работа, которую раньше бы не делали (в отчёте ~27% AI-задач - “не сделали бы иначе”). TELUS, например, сделали 13k внутренних AI-решений и ускорили shipping кода на 30%, сэкономив 500k+ часов.
- Инженерам надо пересмотреть приоритеты - закрывать техдолг и “papercuts” становится выгодно.
• CTO стоит ожидать “взрыва output” и заранее ставить рамки качества, иначе скорость съест поддерживаемость.
Trend 7: Non-technical use cases expand across organizations
Неинженерные команды начинают автоматизировать процессы сами: меньше тикетов в разработку, больше локальных “мини-продуктов”. Zapier в отчёте - 89% adoption и 800+ внутренних агентов; у Anthropic юристы сократили маркетинг-ревью до 24 часов, причём self-service инструменты собрал юрист без опыта кодинга.
- Инженерам надо помогать через внутренние библиотеки/коннекторы/примеры, а не “делать за всех”.
- CTO пора строить governance для citizen devevelopers (что можно автоматизировать, где хранятся секреты, кто отвечает за поддержку).
Trend 8: Dual-use risk requires security-first architecture
Агентный кодинг усиливает и защиту, и атаки. Любой инженер может делать security-review с агентом - и любой атакующий тоже масштабирует свои попытки.
- Инженерам надо двигать практики безопасности: “least privilege” для инструментов агента, изоляция, журналирование, защита от инъекций/подмены контекста.
- CTO надо идти в security by design агентных систем (права, контуры, аудит, red teaming) до того, как агенты получат доступ к продовым данным/деплою.
Если свести отчёт к одному тезису: выиграют команды, которые научатся
- Ууправлять несколькими агентами
- Масштабировать контроль качества
- Безопасно расширить агентные инструменты за пределы инженерии
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
В этом посте мы закончим разбирать короткий trend-report Anthropic, который задает фокус того, что стоит делать в 2026 году нам как инженерам и руководителям, чтобы не отстать от стремительно меняющейся индустрии разработки софта.
3️⃣ Impact trends: What agents may change in 2026
Trend 6: Productivity gains reshape software development economics
Эффект - не только "быстрее", но "больше": растёт объём shipped-результата, появляется работа, которую раньше бы не делали (в отчёте ~27% AI-задач - “не сделали бы иначе”). TELUS, например, сделали 13k внутренних AI-решений и ускорили shipping кода на 30%, сэкономив 500k+ часов.
- Инженерам надо пересмотреть приоритеты - закрывать техдолг и “papercuts” становится выгодно.
• CTO стоит ожидать “взрыва output” и заранее ставить рамки качества, иначе скорость съест поддерживаемость.
Trend 7: Non-technical use cases expand across organizations
Неинженерные команды начинают автоматизировать процессы сами: меньше тикетов в разработку, больше локальных “мини-продуктов”. Zapier в отчёте - 89% adoption и 800+ внутренних агентов; у Anthropic юристы сократили маркетинг-ревью до 24 часов, причём self-service инструменты собрал юрист без опыта кодинга.
- Инженерам надо помогать через внутренние библиотеки/коннекторы/примеры, а не “делать за всех”.
- CTO пора строить governance для citizen devevelopers (что можно автоматизировать, где хранятся секреты, кто отвечает за поддержку).
Trend 8: Dual-use risk requires security-first architecture
Агентный кодинг усиливает и защиту, и атаки. Любой инженер может делать security-review с агентом - и любой атакующий тоже масштабирует свои попытки.
- Инженерам надо двигать практики безопасности: “least privilege” для инструментов агента, изоляция, журналирование, защита от инъекций/подмены контекста.
- CTO надо идти в security by design агентных систем (права, контуры, аудит, red teaming) до того, как агенты получат доступ к продовым данным/деплою.
Если свести отчёт к одному тезису: выиграют команды, которые научатся
- Ууправлять несколькими агентами
- Масштабировать контроль качества
- Безопасно расширить агентные инструменты за пределы инженерии
#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture
Telegram
Книжный куб
[1/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)
Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё…
Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё…
👍8❤2🔥1
Путешествие в Лондон (Рубрика #Travel)
Через пару недель мы с женой сгоняем на недельку в Лондон, где мы побываем впервые:) Когда я начинал учить английский в школе в Северодвинске и проговаривал "London is the capital of Great Britain" я и представить не мог, что когда-то поеду в этот самый London. Правда, сейчас путешествия уже стали рутиной, но я попросил жену добавить в нашу поездку посещение Блетчли-парка, где в период Второй мировой войны в Блетчли-парке располагалось главное шифровальное подразделение Великобритании, а сейчас там расположен Национальный музей компьютеров. Все остальные достопримечательности подбирала моя жена, которой я верю больше чем себе в вопросе планирования досуга:) А ближе к концу апреля мы поедем в Лондон уже с детишками, благо UK - это не Португалия, а значит дает нормальные визы (на полгода).
В общем, я уже предвкушаю интересную поездку:)
P.S.
Если кто 28 февраля будет в Лондоне и захочет пообщаться, то пишите в личку - мы выделили это воскресенье под встречи со своими знакомыми, кого сложно встретить в Москве:)
#Travel #Software #Engineering #History
Через пару недель мы с женой сгоняем на недельку в Лондон, где мы побываем впервые:) Когда я начинал учить английский в школе в Северодвинске и проговаривал "London is the capital of Great Britain" я и представить не мог, что когда-то поеду в этот самый London. Правда, сейчас путешествия уже стали рутиной, но я попросил жену добавить в нашу поездку посещение Блетчли-парка, где в период Второй мировой войны в Блетчли-парке располагалось главное шифровальное подразделение Великобритании, а сейчас там расположен Национальный музей компьютеров. Все остальные достопримечательности подбирала моя жена, которой я верю больше чем себе в вопросе планирования досуга:) А ближе к концу апреля мы поедем в Лондон уже с детишками, благо UK - это не Португалия, а значит дает нормальные визы (на полгода).
В общем, я уже предвкушаю интересную поездку:)
P.S.
Если кто 28 февраля будет в Лондоне и захочет пообщаться, то пишите в личку - мы выделили это воскресенье под встречи со своими знакомыми, кого сложно встретить в Москве:)
#Travel #Software #Engineering #History
1🔥24❤7👍1🌚1