AI-источники: каталог ресурсов для AI-first разработки

40+ ресурсов по трансформации инженерной организации, сгруппированных по темам

30 марта 2026

Подборка статей, инструментов и case studies про AI в разработке. Сгруппировано по темам: SDLC, code review, дисциплина, внедрение, метрики, память агентов, инструменты, отслеживание кода. Каждый ресурс - краткое описание содержания и ссылка на оригинал. Перед каталогом - короткий гид о том, как читать эту подборку, по каким маршрутам идти в зависимости от вашей роли и какие ошибки в работе с источниками встречаются чаще всего. После каталога - короткая карта мыслителей и школ, чтобы можно было ориентироваться в авторстве, а не только в названиях статей.

Как читать этот каталог По задаче: трансформация SDLC По задаче: инженерная дисциплина По задаче: внедрение в команде Антипаттерны чтения и работы с источниками Прикладной гайд: недельный рацион Мыслители и школы Каталог: как меняется SDLC Каталог: code review в эпоху агентов Каталог: инженерная дисциплина как prerequisite Каталог: организационное внедрение Каталог: метрики и измерение эффекта Каталог: память и контекст для агентов Каталог: инструменты и фреймворки Каталог: отслеживание AI-кода и промптов

Как читать этот каталог

Каталог собран не как лента «всё что вышло за последние полгода», а как карта решений, которые приходится принимать инженерной организации, переходящей на AI-first способ работы. У каждого раздела есть свой вопрос: как меняется жизненный цикл разработки, что делать с code review при росте объёма PR, какой минимум инженерной дисциплины нужен, чтобы агенты не превратили команду в фабрику правдоподобного мусора, как централизовать настройки, как измерять эффект, как давать агентам память и контекст, какими инструментами всё это собирать, как помечать AI-сгенерированный код. Если читать подряд - получится длинно и расплывчато; если читать по своему вопросу - получится короче и полезнее.

Аудитория, на которую сделана эта подборка, - инженеры и менеджеры, у которых уже есть продукт, команда и legacy. Не «как попробовать AI на pet project», а «как изменить работу команды из 30-300 человек, не сломав то, что работает». Если ваша задача ближе к exploration на уровне одного разработчика, начинать стоит с четырёх-пяти ссылок (Karpathy, Simon Willison, Anthropic prompt engineering, Hamel Husain), а к этому каталогу возвращаться, когда вы захотите поднять разговор внутри команды.

Я делю ресурсы на три типа по способу потребления. Каркасные читаются внимательно, целиком, с конспектом - это статьи, которые меняют ментальную модель: «The Software Development Lifecycle is Dead» Boris Tane, «AI Is a High-Pass Filter» Bryan Finster, «Company AI Adoption» Will Larson. Прикладные читаются по диагонали и используются как чек-лист или справочник: «AI Is Forcing Us to Write Good Code», документация по skills, OpenSpec docs. Инструментальные вообще не читаются последовательно - это инструменты, которые осваиваются через установку и попытку применить на своём репозитории: RTK, Beads, Langfuse, Superpowers. Перепутать тип = испортить впечатление: попытка «изучить» документацию инструмента целиком превратит её в скучный справочник, а попытка «попробовать» каркасную статью без вдумчивого чтения оставит ощущение, что в ней «и так всё очевидно».

Маршрут «по ролям». Если вы инженер, который хочет ускорить личный workflow, начинайте с раздела «Память и контекст», потом идите в «Инструменты». Если вы тимлид или staff-engineer, отвечающий за внедрение, начните с «Инженерная дисциплина» и «Организационное внедрение», потом - «Метрики». Если вы руководитель инженерной организации, начните с «Как меняется SDLC» и «Code review в эпоху агентов», и только потом погружайтесь в инструменты. Если вы enabler / consultant, читайте всё, но конспектируйте антипаттерны - именно их вам предстоит ловить в чужих командах.

Каталог намеренно вторичен: я собираю и сжимаю чужие тексты, а не создаю первичные исследования. Названные мыслители ниже (раздел «Мыслители и школы») - это первоисточники, к которым стоит идти, когда секция каталога вызвала интерес. Хорошее правило: если вы возвращаетесь к одному и тому же автору в третий раз через мою подборку - откройте его блог напрямую и подпишитесь на RSS, а не ждите, пока я процитирую следующую заметку.

По задаче: трансформация SDLC

Если ваша рабочая боль звучит как «как нам перестроить процесс разработки, когда часть работы делают агенты» - вы попали в самую обсуждаемую тему 2024-2025 годов. Под одну вывеску здесь сходятся четыре разных вопроса, которые часто путают: что происходит с фазами жизненного цикла, как меняется code review, как вести команду в режиме параллельной работы агентов, как подключать enterprise-инфраструктуру. Под каждый - свой минимальный набор источников.

Если вопрос «что происходит с фазами SDLC». Ядро - «The Software Development Lifecycle is Dead» Boris Tane и «Are Code Reviews Dead?» Latent Space. Tane даёт каркас (как меняется каждый этап классики), Latent Space приземляет на конкретный bottleneck (review). Прочитайте эти две статьи целиком, конспект из 5-7 пунктов хватит на полгода обсуждений в команде. Maggie Appleton про Gas Town - длинный разбор оркестратора Стива Йегге; полезен как первый честный анализ multi-agent архитектуры в production-стиле, но это уже второй слой, не для первого подхода.

Если вопрос «что делать с code review». Заходить через «Agentic Code Review» Bryan Finster - двухфазная архитектура (детерминистские проверки + контекстные агенты) - и «Leading an Agentic Development Team» того же автора - четыре практических принципа. Если вы готовы к case study на компанию из BigTech, тогда Block Engineering с Repo Readiness тиром Locked → Novice → Adept → Artisan и методологией RPI (Research → Plan → Implement). Block прозрачно публикует цифры (AI-authored code +69%, automated PRs в 21 раз больше за 3 месяца), что позволяет калибровать собственные ожидания.

Если вопрос «как менять управление командой». Здесь работает связка Bryan Finster (с акцентом на дисциплину delivery) и Will Larson (с акцентом на стратегию adoption). Дополнительно - «Six New Tips for Better Coding with Agents» Steve Yegge, где описывается роль «super-engineer», управляющего десятками агентов, и Merge Wall как структурное ограничение параллельной работы. Эта связка отвечает на вопрос «как мне устроить день моего тимлида или staff-инженера в новой реальности».

Точка входа в каталог: раздел «Каталог: как меняется SDLC» ниже содержит детальные аннотации к этим статьям с конкретными цифрами и тезисами. Используйте текущий раздел как маршрутный лист, аннотации - как памятку перед чтением оригинала.

По задаче: инженерная дисциплина

Тезис, который повторяют почти все авторы каталога, формулируется одной строкой: AI - это high-pass filter. Команды с тестами, типизацией, быстрым CI и продуманной структурой репозитория получают мультипликативный эффект; команды без этого начинают генерировать проблемы быстрее, чем могут их ловить. Это не моральная позиция, а механическое следствие архитектуры агентов: они используют тесты как обратную связь, типы - как сужение пространства поиска, файловую структуру - как контекстный навигатор. Уберите хотя бы один из этих сигналов, и агент перейдёт в режим plausible-looking guesses.

Минимальный набор для понимания темы. «AI Is a High-Pass Filter for Software» Bryan Finster - концептуальная рамка. «AI Is Forcing Us to Write Good Code» Bits by Logic - набор практических рекомендаций (100% coverage, организованная файловая структура, быстрые тесты, ephemeral environments, end-to-end type safety). Профиль Paul Hammond (citypaul) - рабочий пример того, как XP-дисциплина (TDD, парное программирование с агентом) выглядит в живом репозитории. Эту тройку лучше читать в один заход - вместе они образуют связный ответ на вопрос «что нужно сделать с репозиторием перед тем, как давать агенту реальные задачи».

Что добавить, если вы уже согласны с базовым тезисом. Karpathy в YouTube-курсе «Intro to LLMs» и в эссе «Software 2.0» (2017) показывает, почему свойства генерации именно такие, как они есть, - это полезно, чтобы перестать спорить с ограничениями моделей и начать с ними жить. Sebastian Raschka «Build a Large Language Model From Scratch» (2024) - книга, после которой исчезает магия трансформера и появляется инженерное понимание стоимости каждого токена. Hamel Husain пишет про практическую evaluation LLM-приложений; его материалы помогают перейти от «я попробовал, кажется, работает» к «у меня есть тестовый набор, на котором я могу регрессировать качество». Эти три источника - первичные, в каталоге их нет; они расширение для тех, кому нужен следующий уровень глубины.

Чего не делать. Не пытайтесь применить советы Bits by Logic к легаси-кодовой базе без подготовительной работы. 100% coverage, ephemeral environments и end-to-end type safety - это конечная цель, а не стартовая точка. Если у вас 12% покрытия и Postgres-monolith с тысячью миграций, начните с одного куска - вынесите его в отдельный модуль с собственным тестовым стендом, и используйте этот модуль как полигон для AI-разработки. Постепенно расширяйте полигон. Иначе вы будете пытаться внедрить агентов в окружение, в котором они физически не могут получить обратную связь.

Точка входа в каталог: «Каталог: инженерная дисциплина как prerequisite».

По задаче: внедрение в команде

Если ваш вопрос «у нас 50/300/1000 инженеров, как сделать так, чтобы AI принёс измеримую ценность, а не превратился в очередную инициативу с пресс-релизом и без эффекта» - читать стоит в следующем порядке.

Сначала - калибровка ожиданий. «My Team Is Using AI - Why Aren't They 10x Faster?» - применение закона Амдала к AI-инструментам. Если кодирование занимает 20% времени разработчика, ускорение кодирования в 10x даёт лишь 1.22x общего прироста. Эта статья снимает 80% завышенных ожиданий руководства за один заход. Полезна и инженерам, и менеджерам - для разговора с CFO и CEO про реалистичные KPI.

Дальше - стратегия. «Company AI Adoption» Will Larson - флагманский текст про то, как именно устроить процесс внедрения. Larson разбирает hands-on участие лидеров (а не «делегировал и забыл»), единую AI-платформу, централизованное хранение промптов, версионирование конфигов агентов. «Foreign Key Resolution Problem» в этой статье - редкий пример того, как mundane технические барьеры (а не философское сопротивление) блокируют adoption. «Sharing AI Development Rules» Paul Duvall - конкретная архитектура централизации правил по MECE-принципу (Base → Language → Framework → Cloud) с progressive disclosure и 74.4% экономии токенов. Связка Larson + Duvall закрывает вопрос «как организовать adoption на уровне инфраструктуры».

Дальше - метрики. Pragmatic Engineer про метрики - обзор реальных подходов BigTech (Dropbox, Monzo, Microsoft, Glassdoor). Главный практический вывод: 60% лидеров называют отсутствие метрик главной проблемой adoption; acceptance rate теряет значимость; agent telemetry - следующая нерешённая задача индустрии. Дополнительно Sean Goedecke про оценку работы - не про AI напрямую, но про политическую природу estimation, которая становится острее при работе с агентами.

Известные провалы. Один из повторяющихся паттернов провала adoption: компания покупает корпоративный план Copilot или Cursor для 500 инженеров, рассылает ссылку «вот ваша новая суперспособность», и через шесть месяцев усреднённое использование в логах - 8% от лимита. Это стилизованный пример на основе типичных паттернов, но именно эту картинку Will Larson и Bits by Logic описывают как «adoption theater»: лицензии куплены, никто не учил людей, нет champions, нет shared промптов, нет интеграции в CI. Второй паттерн - «inverted рост change failure rate»: команда мерджит на 60% больше PR, но post-deploy инциденты тоже растут, потому что review снят, а quality gates не построены. Тоже стилизованный пример на основе типичных паттернов, но Monzo в обзоре Pragmatic Engineer описывает похожий случай (отключили automated code review «из-за низкой ценности» - читай: ловил мало настоящих проблем и шумел на остальных).

Точка входа в каталог: «Каталог: организационное внедрение» и «Каталог: метрики и измерение эффекта».

Антипаттерны чтения и работы с источниками

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

Hype-cycle reading: «только новое = всегда неполное»

Симптом: вы открываете Twitter / X каждое утро и читаете треды про вчерашнюю модель / релиз / технику. Через месяц у вас в голове набор разрозненных тезисов, ни один из которых не складывается в действие. Причина: новейшее всегда неполно описано - оценочных тестов мало, контекст применения не ясен, чужой опыт не накопился. Лекарство: введите для себя правило «одна каркасная статья (читать целиком, конспект) на каждые десять прикладных постов». Каркасные статьи переживают цикл хайпа; прикладные посты - нет.

Source-mixing without curation: один substack-пост и один arxiv-paper в одной строке выводов

Симптом: в одном тезисе вы ссылаетесь и на peer-reviewed исследование, и на пост анонимного блогера, как на равные основания. Причина: визуально и блог, и paper выглядят одинаково - текст с ссылками. Кажется, что если оба согласны, аргумент сильнее. На самом деле блог часто пересказывает paper с упрощениями, и согласие - артефакт пересказа, а не независимое подтверждение. Лекарство: для каждого утверждения, которое вы хотите взять в работу, задайте себе вопрос «какой класс источника мне это говорит». Paper - класс А (с поправкой на воспроизводимость). Eng-blog от компании, которая платит за результат, - класс B. Личный блог - класс C. Тред в соцсети - класс D. Утверждение, которое стоит на одном D-источнике, не достойно стратегического решения.

Reading without practice: чтение без toy implementation

Симптом: вы прочитали 30 статей про prompt engineering, но ни разу не написали своего агента, который бы читал ваши собственные логи. У вас в голове богатый словарь, но нет ощущения сопротивления материала. Причина: статьи описывают финальный результат после десятков итераций; ощущение «как именно ломается» получается только из своих попыток. Лекарство: на каждую крупную тему - один маленький проект на выходные. После «Build a Large Language Model From Scratch» Раschka - попробуйте дописать nanoGPT Karpathy на токенизаторе из своего корпуса. После Anthropic prompt engineering - напишите агента, который классифицирует ваши Slack-сообщения. Объём результата неважен; важно, что вы один раз прошли цикл.

Ignoring critics: однобокая диета из оптимистичных голосов

Симптом: вы подписаны только на людей, которые верят, что в 2026 году все мы будем «super-engineers, управляющие 50-100 агентами» (цитата из Steve Yegge). Критические голоса (Gary Marcus, François Chollet, Yann LeCun в спорах с генеративной школой) у вас не в ленте. Причина: критика менее эмоционально вознаграждаема в момент чтения, особенно если вы лично инвестировали время в технологию. Лекарство: добавьте в подписку 2-3 публичных скептиков. Не для того, чтобы согласиться, а для того, чтобы каждый раз, когда вы делаете прогноз, спрашивать себя «а как этот прогноз звучит с позиции Маркуса». Часто прогноз становится скромнее и точнее.

Paper-only diet: arxiv без production-перспективы

Симптом: вы читаете 5 paper в неделю, но не открываете ни одного eng-блога. У вас глубокое понимание архитектур, но слабое понимание операционной стоимости запуска модели в production - GPU-цены, p99-латентность, регуляторика, контракты. Причина: paper выглядят «серьёзнее»; eng-blog кажется компромиссом. На самом деле eng-blog описывает реальные проблемы, которые в paper отсутствуют по дизайну (paper про новый алгоритм не описывает, как Stripe или Anthropic обкатывали его в production). Лекарство: на каждые 3 paper - 5 eng-блогов и 1 implementation. Это не научное правило; это эмпирическое отношение, при котором у вас в голове и теория, и практика.

Blog-only diet: чтение только пересказов

Зеркальный антипаттерн. Симптом: вы читаете много мнений практиков, но ни одного оригинального paper. Когда практик ссылается на paper («как показано в X»), вы верите ему на слово. Через год у вас образуется набор устойчивых убеждений, источник которых - один пересказ, который другие пересказы цитируют. Причина: paper трудозатратны. Лекарство: правило «один paper в месяц целиком, с заметками». Любая серьёзная тема (RAG, evaluation, RLHF, agent loops) имеет 3-5 базовых paper, которые имеет смысл прочитать в оригинале. После этого пересказы будут восприниматься осмысленнее.

Single-vendor diet: только Anthropic ИЛИ только OpenAI

Симптом: все ваши закладки про prompt engineering - со страниц одного вендора. Решения, которые вы строите, привязаны к одной модели, одному формату tool calls, одному способу подсчёта токенов. Причина: документация вендора лучше структурирована, проще читается, экономит время. Лекарство: для каждого крупного решения проверяйте, как его делает второй вендор (Anthropic Claude Code vs Cursor / Aider, OpenAI Functions vs Anthropic Tool Use, OpenAI Assistants vs Anthropic Agents). Часто различия мелкие, но они быстро становятся важными при смене провайдера или при работе с клиентом, у которого свой контракт. Source-of-truth diversification - страховка от vendor lock-in на уровне знаний.

Follow-the-loudest: Twitter-сигнал вместо research-сигнала

Симптом: ваше расписание чтения определяется тем, что зашло в вирусный тред. Вы следите за личностями, а не за темами. Причина: алгоритм соцсетей оптимизирует engagement, а не сигнал. Лекарство: ведите явный список тем, которые вам важны (например: evaluation, агент-оркестрация, code review, метрики adoption), и для каждой темы - 2-3 авторитетных автора. Подпишитесь на их RSS / mailing list. Twitter оставьте как «обнаружение нового», но не как основной канал чтения.

Антипаттерны выше я наблюдал у себя в первые 12 месяцев работы с этим каталогом. Они не уникальны и не моральны - это просто то, как ведёт себя любой человек в быстрой области. Вопрос не «как не делать ошибок», а «как заметить их у себя через месяц-два и поправить рацион».

Прикладной гайд: недельный рацион

Мне как читателю помогает простая формула: 3 paper + 5 eng-блог-постов + 1 toy implementation в неделю. Цифры спорные; смысл в пропорции - теория + практика + кодинг. Если у вас нет времени на toy implementation - сократите до 1 paper + 2 поста + 1 час эксперимента в выходные. Если совсем нет ресурса - один длинный пост раз в неделю с конспектом важнее, чем десять прочитанных по диагонали.

Что скимить, что читать глубоко. Глубоко: каркасные статьи (см. раздел «Как читать этот каталог»), paper по теме, в которой вы будете принимать решения в ближайшие месяцы. По диагонали: news-сводки, релиз-ноуты, обзоры моделей, треды в соцсетях. Различить просто: если после прочтения текста ваш next action - «сменю стратегию команды» / «перепишу промпт» / «попробую новый подход в репозитории», читать стоило глубоко. Если next action - «знаю», скимить было достаточно.

RSS + Twitter-листы как гигиена. RSS не умер. Большинство авторов из этого каталога ведут блоги с rss-фидами; подпишитесь на них в любом ридере (Feedly, Inoreader, NetNewsWire) и получайте свежие посты без алгоритмических искажений. Twitter / X имеет смысл использовать через списки: создайте отдельный лист «AI engineering» с 30-50 авторами, читайте только его, не основную ленту. Это снижает hype-нагрузку и одновременно даёт «обнаружение нового».

Источники истины. Несколько сайтов, которые имеет смысл проверять регулярно, не дожидаясь, пока кто-то их процитирует:

Конспект как базовый инструмент. На каждую каркасную статью - короткая заметка из 5-7 пунктов: главный тезис, ключевые цифры, что новое для меня, с чем я не согласен, какой next action. Заметки храните в одном месте (Obsidian, Notion, Markdown в репо) с тегами по темам. Через полгода набор заметок становится полезнее, чем набор прочитанных статей: его можно пересмотреть за час и заметить эволюцию своего мнения.

Мыслители и школы

Каталог ниже - это секундарные источники: я обзорно пересказываю чужие тексты. Чтобы каталог не превратился в lossy-сжатие чужих идей, имеет смысл знать, кто стоит за основными школами. Карта ниже - не претензия на полноту; это minimal viable mapping, чтобы при чтении любой статьи каталога понимать, к какой традиции автор относится и за каким первоисточником стоит идти.

Школа «AI как infrastructure / education»

Школа «Vendor docs as primary source»

Школа «Practitioners / applied LLM»

Школа «Critics / skeptics»

Школа «Engineering discipline meets AI»

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

Каталог: как меняется SDLC

Когда агенты берут на себя кодирование, тестирование и часть review, привлечение узких ролей на каждый этап по умолчанию становится дорогим. Один инженер (или даже заказчик) может контролировать большую часть цикла, подключая специалистов on demand - когда это всплывает по ходу работы, а не потому что так нарисовано в процессе.

Ресурс О чём
The Software Development Lifecycle is Dead
Boris Tane 		Автор разбирает каждый этап классического SDLC и показывает, что с ним происходит при работе с агентами. Requirements и design сливаются с implementation - вместо замороженных спецификаций инженер задаёт направление, а агент генерирует рабочие версии для итеративной доработки. Testing перестаёт быть отдельной фазой: агенты пишут тесты параллельно с кодом, TDD становится их default-поведением. Code review через pull requests превращается в bottleneck - автор предлагает заменить его на agent self-verification и adversarial agent review до автоматических проверок. Deployment становится continuous и decoupled от release. Единственный этап, который выживает почти без изменений - monitoring, но теперь это closed-loop система: телеметрия идёт обратно агентам для автоматического исправления. Итоговая модель: intent → agent execution → observation → iteration. Главный тезис: качество того, что вы строите с агентами, прямо пропорционально качеству контекста, который вы им даёте.
Are Code Reviews Dead?
Latent Space / Ankit Jain 		Статья с конкретными данными: команды с высоким AI adoption мерджат на 98% больше PR, но время review вырастает на 91%. Человеческое ревью не масштабируется при таком объёме. Автор предлагает сдвинуть участие человека upstream - к определению спецификаций и acceptance criteria до генерации кода. Спецификации становятся source of truth вместо кода. Верификация происходит через layered систему: несколько конкурирующих AI-попыток, детерминистские guardrails (тесты, типы, контракты), acceptance criteria заданные до имплементации, permission architectures ограничивающие scope агента, adversarial verification (отдельные агенты проверяют работу). Смена парадигмы: от «Did you write this correctly?» к «Are we solving the right problem?»
Gas Town
Maggie Appleton 		Детальный разбор Gas Town - agent orchestrator Стива Йегге, где специализированные агенты с иерархической структурой (Mayor координирует, Polecats выполняют, Witness контролирует, Refinery управляет merge) работают параллельно. Appleton анализирует архитектуру и приходит к выводу, что система плохо спроектирована, но наглядно демонстрирует критический паттерн: когда агенты берут на себя имплементацию, дизайн и критическое мышление становятся реальным bottleneck. Плохое проектирование до запуска агентов каскадом порождает дорогие проблемы. Также разбирается вопрос Code Distance - насколько близко разработчику стоит оставаться к генерируемому коду, и почему ответ зависит от домена, risk tolerance, размера команды и опыта. Практические рекомендации: stacked diffs вместо традиционных PR, feedback loops через тесты и скриншоты, guardrails через параллельных security и accessibility агентов.
Claude Code and What Comes Next
Ethan Mollick 		Описание эксперимента: Claude Code автономно работал 1 час 14 минут, построив полный стартап-сайт с минимальным вмешательством человека. Mollick разбирает технические механизмы, которые это обеспечили: context compacting (агент создаёт детальные заметки при заполнении контекстного окна), skills (динамическая подгрузка инструкций по ситуации), субагенты (параллельная делегация задач), Model Context Protocol (подключение к внешним системам). Прогноз: новые harnesses, позволяющие AI работать в разных доменах знаний, появятся в ближайшее время. Замечание о текущем состоянии: интерфейсы выглядят как «компьютерная лаборатория 80-х», но AI уже обрабатывает полные циклы разработки.

Каталог: code review в эпоху агентов

Модель «AI пишет код, человек ревьюит» не работает при масштабировании. Объём генерируемого кода растёт быстрее, чем пропускная способность ревьюеров. Альтернатива - двухфазная модель: детерминистские проверки + контекстные агенты-рецензенты. Человек переключается на async review архитектурных решений.

Ресурс О чём
Agentic Code Review
Bryan Finster 		Практический гайд по автоматизации code review через двухфазную архитектуру. Фаза 1 - детерминистские проверки: formatting, linting, static analysis, security scanning, тесты. Эти проверки быстрые, дешёвые и имеют однозначные правильные ответы. Фаза 2 - контекстные агенты, каждый со своей специализацией: Domain Alignment Agent (проверяет терминологию и уровни абстракции), Test Quality Agent (верификация поведения, а не implementation details), Architecture Agent (структурное соответствие), Documentation Agent (актуальность), Naming Coherence Agent (консистентность). Найденные проблемы проходят через self-correction loop: high confidence issues автоматически исправляются, medium confidence предлагаются как diffs, сложные вопросы блокируют review с подробным описанием для человека. Каждый агент конфигурируется: роль, примеры из вашей кодовой базы, ожидаемый формат вывода, границы ответственности. Автор честно описывает ограничения: latency 10-60 секунд, возможные галлюцинации при недостаточном контексте, и то, что система дополняет, а не заменяет человеческое ревью для design decisions.
Leading an Agentic Development Team
Bryan Finster 		Статья о том, как перестроить управление командой при переходе на агентную разработку. Четыре практических принципа. (1) Mission Clarity: начинать с 3-5 предложений о том, что строить и зачем, без указания как - это даёт агентам контекст для архитектурных решений. (2) Define Success Upfront: генерировать Gherkin feature files с тестовыми сценариями до начала кодирования. ATDD на уровне бизнес-сценариев даёт агентам достаточный scope для правильного дизайна. (3) Specialist Team Structure: узкоспециализированные агенты для конкретных аспектов качества (тесты, архитектура, naming, domain patterns) под управлением orchestrating agent. Узкий фокус даёт лучшие результаты, чем монолитные проверки. (4) Hands-Off Governance: после настройки quality pipeline убрать ручное ревью - оно создаёт bottleneck и ломает small batch size. Ключевой тезис: успех зависит не от prompt engineering, а от фундаментальной инженерной дисциплины.
AI-Assisted Development at Block
Block Engineering 		Case study внедрения AI в Block (Square, Cash App, Afterpay, Tidal). Три инициативы: Freedom to Explore (инженеры сами выбирают модели и IDE), AI Champions Program (50 разработчиков по 30% времени на enablement), Training через peer-to-peer brownbags и office hours. Repo Readiness через четыре tier: Locked → Novice → Adept → Artisan - с конкретными действиями на каждом уровне (AGENTS.md, reusable skills, automated PR review, CI/CD tracking). Методология RPI: Research → Plan → Implement - три фазы с fresh context sessions между каждой. Результаты за 3 месяца: AI-authored code +69%, reported time savings +37%, automated PRs в 21 раз больше, 95% инженеров используют AI. Текущий фокус: масштабирование orchestrator adoption для управления параллельными агентами.

Каталог: инженерная дисциплина как prerequisite

AI усиливает существующую инженерную культуру, а не компенсирует её отсутствие. Команды с тестами, type safety и быстрым CI получают мультипликативный эффект. Команды без этого генерируют проблемы быстрее, чем раньше.

Ресурс О чём
AI Is a High-Pass Filter for Software
Bryan Finster 		Центральная метафора: AI работает как high-pass filter - усиливает сильные сигналы и ослабляет слабые. Инженеры с крепким фундаментом получают экспоненциальное ускорение: прототипирование за часы вместо дней, тестирование идей за минуты вместо недель. Инженеры без фундамента генерируют «plausible-looking garbage», не распознавая проблемы. На уровне организации эффект мультиплицируется: компании, оптимизировавшие value flow, получают кратный рост throughput, а дисфункциональные организации просто быстрее копят inventory в существующих bottlenecks. Автор критикует исследования, показывающие минимальный эффект от AI: они измеряют lines of code вместо бизнес-результатов, усредняют данные скрывая расхождение между сильными и слабыми, и не учитывают, адаптировали ли команды свои процессы. Вывод: сначала testing discipline, BDD, continuous integration - потом AI.
AI Is Forcing Us to Write Good Code
Bits by Logic / Steve Krenzel 		Практические рекомендации по подготовке кодовой базы для агентов. (1) 100% code coverage - не как метрика качества, а как verification checklist: при 100% покрытии непокрытые строки однозначно означают новый код без behavioral proof. (2) Организованная файловая структура - файловая система как основной навигатор для агентов: ./billing/invoices/compute.ts передаёт intent лучше IDE-навигации, маленькие файлы не обрезаются при загрузке в контекст. (3) Быстрые тесты - 10 000+ assertions за минуту через кэширование и concurrency, иначе агенты перестают запускать проверки. (4) Ephemeral environments - агенты должны мгновенно получать свежее окружение одной командой. (5) End-to-end type safety - TypeScript, OpenAPI schemas, database constraints: семантические типы (UserId вместо string) сужают пространство поиска для модели. Общий принцип: ограничить degrees of freedom через автоматизацию, чтобы агент фокусировался на доменных задачах.
citypaul (Paul Hammond)
GitHub 		Product-инженер из Манчестера, экспериментирующий с сочетанием Extreme Programming и AI. Его подход - Feedback-Driven Development: AI как pair programmer внутри строгих TDD-циклов (RED-GREEN-REFACTOR). Репозиторий .dotfiles (586 stars) содержит CLAUDE.md с настроенным контекстом для coding-агентов - пример того, как конфигурировать AI-окружение для дисциплинированной разработки. Также: scenarist - E2E testing framework для Node.js с мгновенным переключением сценариев, fullstack-react-tdd-example - TDD в full-stack React. Ценность профиля - рабочий пример того, как XP-дисциплина ограничивает агента от хаотичной генерации.
Тесты - больше не nice-to-have. Без тестового покрытия агент не получает feedback loop и не может верифицировать свои изменения. Ошибки проходят незамеченными и каскадируют. С агентами отсутствие тестов - не технический долг, а производственный risk. Три источника выше сходятся в одном: инвестиция в тестовую инфраструктуру окупается кратно именно потому, что агенты используют тесты как основной механизм self-correction.

Каталог: организационное внедрение

Покупка лицензий и рассылка ссылок не работает. Внедрение требует champions program, централизованного управления промптами, repo readiness тиров и понимания, почему закон Амдала ограничивает наивные ожидания.

Ресурс О чём
Company AI Adoption
Will Larson 		Стратегия AI adoption на уровне компании от автора «An Elegant Puzzle». Larson настаивает на hands-on участии лидеров: «Senior leaders immersing themselves in the details is one of our few defenses» против adoption theater. Конкретные рекомендации: единая AI-платформа с авто-провижинингом аккаунтов, централизованное хранение промптов в доступных базах (промпты - joint property команды, а не личные заметки), git-versioned config для агентов с code review. Подробно разбирается «Foreign Key Resolution Problem» - реальный пример: конвертация «@Will Larson» в Slack ID потребовала три специализированных lookup tool, потому что у Slack-пользователей минимум три способа идентификации. Вывод: барьеры adoption чаще mundane и технические, а не философские. Нон-адоптеров нужно рассматривать как рациональных агентов с обоснованными concerns, а не как resisters.
My Team Is Using AI - Why Aren't They 10x Faster?
Bits by Logic 		Через закон Амдала автор объясняет, почему AI-инструменты не дают кратного ускорения на уровне всей команды. Если кодирование занимает 20% времени разработки, ускорение кодирования в 10x даёт лишь 1.22x общего прироста. Инженеры AWS тратят на код около 1 часа в день - остальное уходит на митинги, координацию и stakeholder management. Значимый эффект появляется, только когда атакуются все bottlenecks одновременно: agentic PRD generation, automated code reviews, 100% test coverage, automated documentation, минимизация митингов. Маленькие команды выигрывают от AI непропорционально - у них доля кодирования в общем времени выше. Следующий bottleneck появляется сразу после устранения предыдущего.
Sharing AI Development Rules Across Your Organization
Paul Duvall 		Подход к централизации AI-инструкций (CLAUDE.md, rules, skills) на уровне организации. Без централизации: inconsistent правила, tribal knowledge, невозможность аудита. Решение - четырёхмерная структура по MECE-принципу: Base (универсальные правила) → Language-specific → Framework-specific → Cloud provider. Progressive disclosure загружает только контекстно-релевантные правила, что даёт 74.4% экономию токенов. Версионирование через GitHub releases обеспечивает reproducible, auditable deployments. Локальные override через merge-стратегии позволяют проектным кастомизациям. Ключевая проблема, которую решает: новые разработчики тратят дни на то, чтобы «figure out how we do AI here». Правила для AI-агентов нужно версионировать и деплоить как инфраструктурный код.
My Experience with Claude Code
Sankalp 		Практические наблюдения из повседневного использования Claude Code. Эффективное контекстное окно составляет 50-60% от заявленного из-за overhead tool calls. Opus 4.5 превосходит GPT-5.1-Codex по скорости и качеству коммуникации. Конкретные рекомендации: (1) exploration first - задавать уточняющие вопросы и понять requirements до начала кодирования, (2) cross-model verification - использовать другую модель для code review и поиска багов, (3) запускать compaction или новую сессию при 60% заполнении контекста, (4) инвестировать в domain knowledge - чем глубже понимание предметной области, тем точнее промпты. Интересное наблюдение: системы типа Manus используют todo-списки для «reciting objectives into the end of context», предотвращая goal drift в длинных agent loops. On-demand skill loading предпочтительнее статических system prompts - экономит контекстное окно.

Каталог: метрики и измерение эффекта

60% лидеров называют отсутствие метрик главной проблемой AI adoption. Измерять нужно скорость, качество и maintainability одновременно, а не по отдельности. Acceptance rate теряет значимость. Agent telemetry - следующая нерешённая задача.

Ресурс О чём
How Tech Companies Measure the Impact of AI
Pragmatic Engineer 		Обзор метрик AI-эффекта с реальными данными от крупных компаний. Базовые метрики: PR throughput и cycle time, change failure rate, developer satisfaction, time savings per engineer, code maintainability perceptions. Данные компаний: Dropbox (90% adoption, AI-юзеры мерджат на 20% больше PR при снижении change failure rate), Monzo (AI экономит 40-60% на миграциях, но automated code review отключили из-за низкой ценности), Microsoft (отслеживают «bad developer days» как индикатор friction), Glassdoor (измеряют experimentation outcomes через A/B тесты в месяц). Acceptance rate теряет значимость как метрика - компании понимают, что она не захватывает реальный impact. Cost analysis underdeveloped: большинство организаций избегают explicit spend tracking, чтобы не тормозить adoption. Прогноз: agent telemetry потребует новых метрик через 12-18 месяцев, вендоры намеренно делают телеметрию непрозрачной для конкурентного преимущества.
How I Estimate Work
Sean Goedecke 		Статья не про AI напрямую, но про фундаментальную проблему estimation в software engineering, которая становится ещё острее с агентами. Главный тезис: точная оценка software work невозможна, потому что unknown work всегда доминирует. Оценки служат политическим целям - менеджеры используют их для решения, какие проекты финансировать. Практический подход: работать от implicit timeline менеджмента, предлагая несколько технических подходов с разными tradeoffs. Отказ от оценок - трусость, потому что заставляет менее технических людей оценивать за вас. Хорошо работающие команды часто пропускают estimation на continuous-value проектах. Senior-инженеры строят «trust capital», который работает только при pragmatic estimates большую часть времени.
Для сбора статистики использования Claude Code существует open-source инструмент ccusage - CLI, который парсит локальные логи и генерирует отчёты по токенам, стоимости и частоте вызовов. Данные агрегируются локально без отправки на внешние серверы.

Каталог: память и контекст для агентов

Агенты не помнят ничего между сессиями. Каждый новый разговор - «50 First Dates». Решения варьируются от structured memory (Beads) до иерархических context files (CLAUDE.md → skills → knowledge base) и queryable документации вместо prose.

Ресурс О чём
Introducing Beads
Steve Yegge 		Beads (bd) - distributed issue tracker, спроектированный для AI-агентов. Данные хранятся в JSONL в git (без серверов), queryable через CLI (bd ready --json для списка unblocked задач). Hash-based ID (bd-a3f2) предотвращают коллизии при multi-agent работе. Четыре типа зависимостей: blocks, parent-child, related, discovered-from. Конфигурация - одна строка в CLAUDE.md. Проблема, которую решает: markdown-планы - это «write-only memory» без возможности запросов, агенты теряют контекст после compaction и начинают recursive re-planning. В тесте агент за 30 секунд создал 128 issues (включая epics с interdependencies) из десятилетнего TODO-списка. Ключевое наблюдение: когда агенты встречают Beads, они сами начинают advocate за его использование - система naturally aligns с тем, как AI-модели обрабатывают информацию.
Six New Tips for Better Coding with Agents
Steve Yegge 		Шесть практических рекомендаций от автора Beads. (1) Software теперь throwaway - ожидаемый срок жизни кода меньше года, генерация дешевле рефакторинга. (2) Agent UX имеет такое же значение, как human UX - проектируйте инструменты под то, как агенты работают, итерируйте наблюдая за их failures. (3) 40% времени на code health - еженедельные ревью code smells, redundant систем, архитектурных проблем до того, как они compound. (4) Некоторые проекты опережают время - лучше поставить на паузу и вернуться с новыми моделями. (5) Rule of Five - прогоняй агента через 4-5 review cycles: поздние итерации ловят архитектурные проблемы, пропущенные в первых проходах. (6) Swarm where you can - параллельные агенты ускоряют работу, но создают Merge Wall: конфликты требуют serialized rebases. Дополнительно: AI-когниция деградирует на границах систем (RPC, database calls, IPC), и к 2026 году появится новый класс «super-engineers», управляющих 50-100+ агентами.
Beads: Git-Backed Issues
Ian Bull 		Независимый обзор Beads от стороннего разработчика. Описывает паттерн «Descent Into Madness»: после context compaction агент теряет outer context задачи, начинает рекурсивно перепланировать уже решённые подзадачи и в итоге объявляет проект «done», игнорируя основной объём работы. Beads решает это через structured data с queryable зависимостями - агент в любой момент может запросить bd ready и получить актуальный список unblocked задач. Синхронизация через git: JSONL как distributed database без серверов, автоматический export из SQLite в JSONL и import при pull. Ценность статьи: объяснение от пользователя, а не автора, с фокусом на конкретные проблемы, которые Beads решает в реальном workflow.
Claude Code Skills
Anthropic 		Официальная документация по skills - механизму расширения Claude Code через SKILL.md файлы с YAML frontmatter. Skills следуют open standard (agentskills.io), портируемому между платформами. Progressive disclosure в три уровня: YAML frontmatter (всегда загружен - имя, описание, trigger conditions), body SKILL.md (загружается при релевантности), linked files (подгружаются по необходимости). Препроцессинг через !`command` - shell-команды выполняются до того, как Claude видит содержимое, позволяя инжектировать live data (git status, API responses, PR diffs) прямо в prompt. Четыре уровня приоритета: Enterprise > Personal > Project > Plugin. Контроль вызова: disable-model-invocation: true для skills с side effects (deploy, commit), user-invocable: false для фоновых знаний. Рекомендация: держать SKILL.md под 500 строк, выносить reference material в отдельные файлы.
Complete Guide to Building Skills for Claude
Anthropic (PDF, 32 страницы) 		Официальный гайд Anthropic по созданию skills. Структура skill: папка с SKILL.md (обязательно, exact case-sensitive naming), плюс опциональные scripts/, references/, assets/. Три категории skills: Document/Asset Creation, Workflow Automation, MCP Enhancement. Пять design patterns: sequential workflow orchestration, multi-MCP coordination, iterative refinement, context-aware tool selection, domain-specific intelligence. Trigger-phrase engineering - критический аспект: description должен содержать WHAT и WHEN (до 1024 символов), первые фразы самые важные (truncation на 250 символах). Тестирование: triggering tests (активируется ли при нужных условиях?), functional tests (правильный ли output?), performance comparison (лучше ли baseline?). Дистрибуция через Claude.ai Settings или CLI directory, organization-level deployment доступен с декабря 2025. API доступ через /v1/skills.

Каталог: инструменты и фреймворки

Экосистема инструментов для AI-first разработки: от сжатия токенов и observability до spec-driven planning и security skills.

Оптимизация контекста

Инструмент О чём
RTK (Rust Token Killer) CLI-прокси на Rust (single binary, zero dependencies), который фильтрует и сжимает вывод shell-команд перед отправкой в контекстное окно LLM. Сжатие 60-90% токенов: ~94 000 tokens saved за типичную 30-минутную сессию Claude Code. После rtk init -g команды вроде git status прозрачно перехватываются и сжимаются - ни агент, ни пользователь не замечают подмены. Работает с Claude Code, Copilot, Cursor, Gemini CLI, Cline, Windsurf. Покрывает git, file operations, test runners (pytest, cargo test, vitest), linters, package managers, containers.
Context Hub CLI-инструмент (npm: @aisuite/chub), предоставляющий coding-агентам курированную, версионированную API-документацию. Агент ищет документацию (chub search "stripe payments") и подгружает language-specific версии. Инкрементальная загрузка: только нужные секции, экономия токенов. Локальные аннотации сохраняются между сессиями - при следующем запуске заметки агента подгружаются автоматически. Community feedback loop: агенты upvote/downvote документацию, рейтинги уходят мейнтейнерам. Всё содержимое - open-source markdown, knowledge layer прозрачен и поддерживается сообществом. Решает две проблемы: галлюцинации API и повторный поиск одной и той же информации в каждой сессии.
LSP для Claude Описание того, как Claude Code подключается к Language Server Protocol серверам (tsserver, pylsp, rust-analyzer и др.) автоматически, без ручной конфигурации. Claude получает доступ к тем же семантическим данным, что и IDE: instant diagnostics, go-to-definition, find-all-references, полные type signatures. Ключевое следствие: «reading code» и «understanding code» - разные вещи. Когда Claude анализировал код как plain text, он пропускал семантическую информацию. С LSP зазор между «Claude-approved code» и production-ready code сокращается. Практические рекомендации: доверять diagnostic alignment между Claude и IDE, просить type structure explanations перед рефакторингом, валидировать сгенерированный код на type errors немедленно.

Observability и tracking

Инструмент О чём
MLflow Крупнейшая open-source AI engineering платформа (30M+ monthly downloads, 20K+ GitHub stars, 900+ contributors). Tracing на OpenTelemetry для любого provider/framework. 50+ встроенных метрик и LLM-judges для оценки качества и обнаружения регрессий. Prompt management с version control и full lineage tracking. AI Gateway - unified OpenAI-compatible интерфейс для routing, rate limiting и cost control между providers. Agent Server на FastAPI с автоматической валидацией и tracing. Мост между традиционным ML tracking и современным LLM/agent observability в одной платформе. Минимальный setup: запуск сервера + 3 строки кода для включения логирования.
Langfuse Open-source LLM observability платформа для debug, анализа и итераций над LLM-приложениями. Tracing всех LLM и non-LLM вызовов (retrieval, embeddings, API), визуализация agent workflows как графов, multi-turn conversation tracking. Timeline inspection для debug latency, per-user cost/usage tracking, real-time dashboards по quality/cost/latency. Prompt management с версионированием и deployment. Evaluation: LLM-as-a-judge, user feedback, custom metrics. 50+ интеграций с библиотеками и фреймворками, OpenTelemetry compatibility. Self-hostable, fully open-source. Выходит за рамки чистого мониторинга - полный lifecycle tool от prompt management до production evaluation.

Планирование и workflow

Инструмент О чём
OpenSpec Lightweight spec-driven framework для планирования features до написания кода. Генерирует спецификации, design documents, implementation tasks и requirement deltas. Change Proposals содержат technical design и декомпозированные задачи. Spec Deltas показывают, как меняются requirements - code review фокусируется на intent, а не implementation. Specs живут в репозитории как version-controlled artifacts, создавая постоянную, reviewable запись архитектурных намерений. Интеграция с 30+ coding agents (Claude Code, Cursor, GitHub Copilot, Gemini CLI). Философия: «Get to a good enough plan and start coding» - мост между vibe-coding и rigid waterfall. Решает проблемы: misalignment до начала кодирования, потеря контекста при смене разработчика, понимание intent vs. текущая implementation в brownfield проектах.
Superpowers Plugin-система с composable skills, которая навязывает дисциплинированные software engineering workflows AI-агентам. Семь этапов: (1) Brainstorming - collaborative design refinement с валидацией от пользователя, (2) Git Worktrees - изолированные ветки для параллельной работы, (3) Planning - декомпозиция на задачи по 2-5 минут, (4) Execution - субагенты с двухуровневым ревью, (5) TDD - принудительный RED-GREEN-REFACTOR цикл, (6) Code Review - автоматические проверки до merge, (7) Finishing - cleanup и merge decision workflows. Принцип «evidence over claims»: агент обязан доказать, что код работает, а не декларировать это. Поддержка concurrent субагентов. Ценность: вместо надежды на хорошие решения агента, хорошие решения делаются обязательными через процесс.
BMAD Method Open-source AI-driven agile framework со структурированными workflows и специализированными agent personas. 34+ workflows от анализа до deployment, 12+ персон (product manager, architect, developer, UX designer, Scrum master и др.). «Party Mode» позволяет нескольким агентам-персонам работать в одной сессии. Scale-adaptive intelligence автоматически подбирает глубину планирования по сложности проекта. Модульная экосистема: BMad Builder, Test Architect, Game Dev Studio, Creative Intelligence Suite. Подход: AI как collaborative partner через facilitated workflows и domain expert персоны, а не автономный генератор кода. Human-in-the-loop на каждом этапе для контроля качества.

Безопасность

Инструмент О чём
Semgrep Skills Коллекция security skills для AI-агентов, построенная на базе Semgrep detection rules и упакованная в Agent Skills format. Три пакета: code-security (OWASP Top 10, infrastructure security, secure coding для 15+ языков), llm-security (OWASP Top 10 рисков для LLM-приложений: prompt injection, data poisoning, insecure output handling), semgrep (запуск сканов и создание кастомных detection rules). Pattern-based vulnerability detection + taint analysis для injection attacks. Тестирование правил через test-driven подход. CI/CD pipeline integration. Ценность: security expertise, демократизированное через embedding в AI-ассистента - агенты проактивно находят уязвимости при генерации и ревью кода, security становится частью потока работы, а не отдельным этапом.
Vercel React Best Practices - 40+ правил оптимизации React, упакованных как Agent Skills и устанавливаемых на несколько AI-платформ. Правила приоритезированы по impact: сначала устранение request waterfalls и снижение bundle size, затем server-side performance и client-side fetching, затем advanced patterns. Практики извлечены из production codebases, компилируются в queryable AGENTS.md. Пример того, как domain-specific knowledge упаковывается в portable формат для повторного использования агентами между проектами.

Каталог: отслеживание AI-кода и промптов

Когда значительная часть кода генерируется агентами, возникают практические вопросы: как отличить AI-код от ручного, как собирать промпты для анализа, как получить статистику использования.

Маркировка AI-сгенерированного кода

Block использует Co-Authored-By в commit messages для автоматических PR. Это минимальный, совместимый с git подход, который позволяет фильтровать AI contributions через git log --grep="Co-Authored-By". Альтернатива - инструктировать агента добавлять комментарии в код (# AI-generated), но это загрязняет codebase и плохо масштабируется. Третий вариант - metadata в CI pipeline: тег на PR или label, указывающий процент AI-authored кода.

Сбор промптов

Will Larson рекомендует хранить промпты централизованно как shared property команды. Два уровня:

Статистика использования

Инструмент О чём
ccusage Open-source CLI для парсинга локальных логов Claude Code. Генерирует отчёты по количеству токенов, стоимости и частоте вызовов. Позволяет понять, как именно команда использует AI: какие задачи, какие модели, какой объём контекста. Данные агрегируются локально без отправки на внешние серверы.
MLflow / Langfuse Для команд, строящих собственные AI-интеграции (internal tools, custom agents, RAG-пайплайны): tracing запросов к LLM, cost tracking по пользователям и проектам, quality evaluation через LLM-judges и custom metrics. Детальное описание обоих инструментов - в секции «Каталог: инструменты и фреймворки» выше.
Pragmatic Engineer: agent telemetry - следующая нерешённая задача в индустрии. Существующие метрики (PR throughput, acceptance rate) не захватывают работу агентов - автономные PR, multi-step reasoning, tool usage. Через 12-18 месяцев потребуются новые метрики. Вендоры намеренно делают телеметрию непрозрачной для конкурентного преимущества - имеет смысл инвестировать в собственные инструменты сбора данных.