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

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

30 марта 2026

Справочник

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

Как читать этот каталог По задаче: трансформация SDLC По задаче: инженерная дисциплина По задаче: внедрение в команде Антипаттерны чтения и работы с источниками Прикладной гайд: недельный рацион Мыслители и школы Каталог: как меняется SDLC Каталог: code review в эпоху агентов Каталог: инженерная дисциплина как prerequisite Каталог: организационное внедрение Каталог: метрики и измерение эффекта Каталог: память и контекст для агентов Каталог: инструменты и фреймворки Каталог: отслеживание 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 на уровне инфраструктуры».

Метрики внедрения. При чтении обзоров смотрите, как авторы измеряют использование инструментов, качество и время работы. Процент принятого кода и число лицензий не показывают результат сами по себе. Сравнивайте определения и условия измерений.

Примеры проблем внедрения. Покупка лицензий без обучения, поддержки и проверки результата может не изменить работу команды. Увеличение числа PR при прежних проверках может увеличить нагрузку на ревью. Это сценарии для диагностики, а не статистика конкретных компаний.

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

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

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

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

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

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-сводки, релиз-ноуты, обзоры моделей, треды в соцсетях. Различить просто: если после прочтения текста ваш следующий шаг - «сменю стратегию команды» / «перепишу промпт» / «попробую новый подход в репозитории», читать стоило глубоко. Если следующий шаг - «знаю», скимить было достаточно.

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

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

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

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

В каталоге я кратко пересказываю чужие тексты. Для принятия решения стоит открыть оригинал и проверить аргументы автора. Карта ниже помогает понять, с какими подходами связаны материалы и какие первоисточники искать дальше.

Школа «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, цикл обратной связиs через тесты и скриншоты, 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. Без тестового покрытия агент не получает цикл обратной связи и не может верифицировать свои изменения. Ошибки проходят незамеченными и каскадируют. С агентами отсутствие тестов - не технический долг, а производственный 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 загружает только контекстно-релевантные правила, В материале обсуждается экономия токенов; для своей конфигурации ее нужно измерить отдельно. Версионирование через 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 - экономит контекстное окно.

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

Метрики внедрения. При чтении обзоров смотрите, как авторы измеряют использование инструментов, качество и время работы. Процент принятого кода и число лицензий не показывают результат сами по себе. Сравнивайте определения и условия измерений.

Ресурс О чем
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, которая становится еще острее с агентами. Автор разбирает, как неизвестные детали задачи влияют на оценку сроков. Оценки служат политическим целям - менеджеры используют их для решения, какие проекты финансировать. Практический подход: работать от implicit timeline менеджмента, предлагая несколько технических подходов с разными компромиссы. Автор считает, что инженер должен участвовать в обсуждении сроков, чтобы технические ограничения учитывались при планировании. Хорошо работающие команды часто пропускают 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 цикл обратной связи: агенты 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 месяцев потребуются новые метрики. Вендоры намеренно делают телеметрию непрозрачной для конкурентного преимущества - имеет смысл инвестировать в собственные инструменты сбора данных.