Каникулы ещё не закончились – самое время спокойно почитать что-нибудь полезное.

Собрал подборку лучших постов за прошедший год – если пропустили или хотите вернуться к избранному:
– Зачем нужен шаблонный сервис и пример такого сервиса на FastAPI
– Чтобы провести встречу продуктивно, нужно постараться. Мы написали, что сами применяем на практике
– Видео про роли в крупном проекте – аналитики, разработчики, тестировщики и как всё это живёт вместе
– Набор заметок о том, зачем нужны архитектурные схемы, как их составлять и где проходят зоны ответственности
– Пост-стенание на тему код-ревью
– Революционный метод организации рабочих чатов
– Сайт с сериалами на разных языках и бот для изучения иностранного языка методом карточек
– Мой опыт работы с ai-агентами
– Приём, который помогает быстрее принимать решения в команде
– Как не забивать на написание постмитов
– Статья о том, как написать своего первого ai-агента
– Советы и антипаттерны при работе с Postgres
– Очень крутой курс по System Design, который искренне рекомендую

#devfm #backup

Еще один способ работать с ai-агентами

Завтра начинаем работать, но никогда не поздно начать то, что давно откладывал.

Сейчас AI-агенты, действительно, умеют многое. И если с большими проектами всё ещё бывает непросто, то для MVP или пет-проекта – это супер классный инструмент.

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

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

Рекомендую попробовать spec-kit.

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

Главный плюс такого подхода – он сам подталкивает к определённому флоу, чтобы ничего не забыть. Явно подсказывает следующий шаг. Если прервался – можно продолжить с того же места. Поддерживается разными агентами: Claude Code, Copilot, Cursor и другими.

Мне нравится пробовать на пет-проектах то, что давно откладывал. Делегировать то, в чём скучно разбираться самому.

Например, чтобы подбить статистику по популярным постам, я сделал небольшой сервис tganalytics – собирает информацию из любого публичного канала в Telegram и позволяет сортировать посты по популярности.

Из полезного:
– когда подписываешься на новый канал – удобно посмотреть самые популярные посты
– бэкап собственного канала
– база для RAG и собственной базы знаний
– выгрузка контента – я так делаю для кулинарных каналов

Если интересно – заходите, попробуйте. А если что-то не полетит – приходите, поправлю.

Среди похожих инструментов для работы с агентами стоит посмотреть на SuperClaude, но мне он показался переусложненным.

#ai

Я в целом скептически отношусь к курсам. Но так вышло, что как-то время от времени присматривался к курсам Стратоплана – и тут ребята сами предложили пройти у них обучение на курсе CTO.

Сначала подумал: столько в меня не влезет. А потом решил – почему бы и нет. Впихнуть невпихуемое – это мое:)

Хочу структурировать имеющиеся знания, проверить их актуальность и пообщаться с людьми со схожими запросами. Такой осознанный нетворкинг.

Поступление состоит из двух этапов.

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

Правда, решать кейсы в вакууме мне сложно. Сложно вжиться в абстрактную ситуацию с безликими героями. И тут для себя выработал лайфхак: отбросить мишуру и перенести суть проблемы на свой проект. Вместо безликих героев назначить своих коллег – и кейс сразу играет новыми красками. Начинают приходить хорошие идеи и решения.

Второй этап – что-то вроде собеседования. Но по сути это просто обсуждение твоего опыта, чтобы подобрать группу, с которой будешь плотно работать в процессе.

В итоге я попал на курс, любопытно, что из этого получится. Буду делиться полезными инсайтами.

Когда у задачи нет даты

Я уже рассказывал, как организую свои задачи. Сегодня про один приём, который мне сильно помогает.

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

Но есть такие задачи, которые не привязаны к дате – они привязаны к событию.
Примеры из жизни: “когда поеду в Сочи – сходить в такое то место”, “когда будет синк по проекту – обсудить текущий CI/CD”. У этих задач нет конкретной даты, и непонятно, куда их складывать. Если просто кинуть в общий список – они точно потеряются. Если поставить произвольную дату – будут раздражать напоминаниями не в тот момент и постоянно еще придется переносить.

И вот тут мне помогают теги. Я размечаю такие задачи по событию: #сочи, #ретро, #созвон-с-заказчиком. Когда событие наступает – открываю нужный тег и вижу всё, что хотел сделать или обсудить.

Иногда у события есть конкретная дата – например, еженедельный 121 с коллегой. Казалось бы, можно вести отдельный списочек для каждого человека и перед встречей туда заглядывать. Но на практике это неудобно: нужно помнить, где этот список лежит, каждый раз туда заходить, что-то добавлять. А с тегами проще — в любой момент кидаешь задачу в общий инбокс, помечаешь #вася, и забываешь. На открываешь заметки по конкретному тегу – всё перед глазами.

В общем мне такой прием помогает. Пользуетесь ли чем-то подобным?

#devfm #productivity

Кто такие Skills в ai-агентах?

AI-агенты ехают и бибикают в индустрии. Использование MCP уже стало для всех обыденностью, но с ними есть известная проблема – они жрут токены. Если подключено несколько MCP-серверов, то только начав диалог с агентом, половина контекста может улететь.
И вот тут недавно появилась интересная штука – Skills.

Сначала я подумал: ну что за зверь такой? Есть же уже команды, субагенты, MCP. Зачем нам еще Skills?

Одна из главных фишек – скилы грузятся на лету и поэтапно, а не всё сразу.

Три уровня загрузки:
– Level 1 – Metadata. Загружается всегда при старте. Это просто name и description из YAML-шапки. Claude знает только, что скилл существует и когда его использовать
– Level 2 – Instructions. Загружается, когда скилл триггерится. Основное тело SKILL.md с инструкциями и воркфлоу
– Level 3 – Resources. Загружается по необходимости. Дополнительные файлы, скрипты, шаблоны

То есть если у вас скилл для написания e2e-тестов – он подгрузится только когда речь зайдёт об e2e. До этого момента в контексте болтается только одна строчка с описанием.

Что внутри скилла
Скилл – это не просто файлик с инструкциями. Это директория с модульной структурой. Можно разбивать знания на отдельные файлы – агент подгрузит только то, что нужно для конкретной задачи. Можно добавлять скрипты – и тогда в контекст попадёт только результат выполнения, а не сам код.
Скилы сейчас поддерживаются всеми основными агентами: Cursor, Claude Code, Codex.

Я, например, использую:
– Playwright Skill – описываешь задачу на естественном языке, агент сам пишет и выполняет автоматизацию браузера. Открывается реальное окно, видишь что происходит, получаешь скриншоты и логи
– Frontend Design Skill – на тот случай, когда нет дизайнера, но хочется сделать достаточно хорошо. По умолчанию агенты генерируют типичный дизайн сильно так себе. Скилл содержит рекомендации по типографике, цветам, анимациям – и результат становится заметно лучше

#ai

Правило трёх итераций – когда диалог зашел в тупик

Бывает обсуждаете что-то с коллегой или смежниками, не можете договориться. Обмениваетесь аргументами раз, два, три – и всё никак. Такой словесный пинг-понг получается.

И в этом потоке обсуждения почему-то кажется, что ещё одна итерация – и точно договоримся. Ещё раз объясню свою позицию, приведу новый аргумент, и собеседник наконец поймёт.

На практике обычно так не работает. Если за три итерации обмена мнениями вы не сдвинулись с места – скорее всего, дальше будете ходить по кругу. Каждый повторяет свои аргументы чуть другими словами, но позиции не меняются. И это продолжается, пока просто не закончится отведённое на встречу время. А потом все разойдутся с ощущением, что встреча была ни о чем, ни к чему не пришли.

Поэтому после трех итераций – полезно притормозить. Что-то явно не так. Может, нужны артефакты – данные, метрики, примеры из прода. Может, не хватает контекста, который есть у кого-то третьего. А может, ваш собеседник просто упёрся – и тогда нужна эскалация или человек, у которого есть полномочия рассудить разногласия. Отложите, соберите отсутствующие пазлики и вернитесь к вопросу.

Три итерации – и тормозим, работает удивительно хорошо.

#devfm

Субботнее развлекательное

Бывает сидишь себе спокойно в общественном месте, а какой-то неразумный человек включает видяшку на полную громкость. Без наушников. ААА!!!

Нашёлся человек, который решил эту проблему по-инженерному – написал STFU.

Идея простая: открываешь сайт, и он начинает дублировать любой звук вокруг. С небольшой задержкой. То есть человек слышит своё же видео дважды – и это настолько раздражает, что скорее всего он сам выключит свою херабору.

Исходники тоже есть – можно глянуть.

RAG на практике

RAG – наверное, второе по популярности слово в индустрии после ai-aгент. Всем нужен RAG.

Наткнулся на статью победителя RAG Challenge. Это соревнование, где нужно было за 2.5 часа спарсить 100 PDF-отчётов (до 1000 страниц каждый) и построить QA-систему. Автор занял первое место. В статье описал весь пайплайн, показал код, рассказал, на какие грабли наступил – получилось очень интересно и практично.

Парсинг
Первый этап – превратить PDF в текст. Казалось бы, стандартная задача. Автор перепробовал пару десятков парсеров и пришёл к выводу: нормальных не существует. Таблицы разваливаются, многоколоночный текст путается. Пришлось форкнуть Docling и допиливать руками.

Индексация
Дальше текст нарезается на куски и складывается в векторную базу для поиска. Ключевое решение – отдельная база на каждую компанию. Зачем мешать метрики разных компаний в одну кучу? Область поиска сразу сужается в 100 раз.

Поиск
Векторный поиск возвращает топ-N результатов, но ранжирует их довольно грубо – при векторизации часть смысла теряется. В итоге в топ-10 попадает релевантная информация, но не всегда на первых местах.

Логичная идея – добавить классический текстовый поиск (BM25) и скомбинировать результаты. Автор попробовал – не зашло. Гибридный поиск чаще ухудшал качество, чем улучшал.

Зато сработал другой подход: достаём топ-30 из векторного поиска и просим gpt-4o-mini оценить релевантность каждого куска. Получается точнее, чем любой алгоритмический реранкинг. И стоит меньше цента на вопрос.

Генерация ответа
Чем больше правил даёшь модели в одном промпте, тем хуже она им следует. Модель начинает что-то игнорировать или путать.

Решение – роутинг, в зависимости от типа ожидаемого ответа вопрос уходит в разные промпты. В каждом – только релевантные правила.

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

Помогает Structured Output + Chain of Thought: модель сначала рассуждает в отдельном поле, анализирует контекст с разных сторон, и только потом даёт ответ. Это заметно снижает количество галлюцинаций.

Неоднозначность
Отдельная история – что вообще считать правильным ответом. «Who is the CEO?» – звучит просто. Но CEO это только Chief Executive Officer? Или Managing Director тоже подходит? А President? И таких вопросов в бизнес-области может быть мильон.

Автор называет это – порогом свободы интерпретации. И его приходится калибровать с заказчиком вручную, разбирая edge cases.

Вывод такой, что для построения RAG нет одного магического решения. Качество складывается из мелочей на каждом этапе. И чем глубже понимаешь задачу – тем точнее можешь эти мелочи настроить.

Статью очень рекомендую.

#ai

Не могу не поделиться. Александр Поломодов часто пишет и выступает про System Design. Особенно много внимания уделяет System Design интервью.

И вот он собрал многие материалы в одном месте – сделал сайт , посвящённый этой теме.

Если вам актуально – очень рекомендую заглянуть. Надеюсь, проект будет развиваться.

Управление изменениями
Книга "Управление изменениями без потрясений и конфликтов" Адизеса

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

Помимо практики, мне нравится читать книги, которые под эту практику подводят теорию. Знания становятся более структурированными.

Одна из областей, где давно хотел систематизировать знания – понимание особенностей людей. Какие бывают типы, как они действуют, принимают решения. Интуитивно понимаю, что делать, но четкой структуры не было. Решил начать с классики – Адизеса.

Природа изменений
Адизес начинает с того, что изменения неизбежны, а любое изменение порождает проблемы. И эти проблемы необходимо решать – пока никаких открытий:)

PAEI: разные люди – разное восприятие
Чтобы решать проблемы и проводить изменения, нужно сначала спланировать, а потом воплотить решение. И для этого нужны разные роли – Адизес называет их PAEI. Не буду раскрывать модель подробно, это лучше читать в оригинале, но суть в том, что разные типы людей буквально живут в разных системах координат.

Они по-разному расставляют приоритеты: одному важно сделать результат здесь и сейчас, другому – выстроить порядок и процессы, третьему – увидеть новые возможности, четвёртому – чтобы команда была согласна и двигалась вместе.

Они по-разному понимают одни и те же слова. "Да" для одного типа – это действительно "да". Для другого может означать "может быть". А для третьего – вежливый способ сказать "нет".

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

Конфликт как норма
А раз люди разные – конфликт неизбежен. Один хочет делать сейчас, другой хочет сначала всё продумать, третий хочет менять направление, четвёртый хочет чтобы все договорились. Адизес утверждает, что конфликт – по сути необходимое условие хорошего решения. Плохо не когда команда спорит, а когда не спорит – значит кто-то молчит или всем всё равно.

Но конфликт бывает конструктивным и деструктивным. Разница – во взаимном уважении и доверии. Если они есть, разногласия ведут к лучшим решениям. Если нет – то ничего хорошего не получится.

CAPI: почему недостаточно быть правым
Допустим, команда прошла через конструктивный конфликт и нашла хорошее решение. Достаточно ли этого, чтобы изменение произошло?

Адизес вводит концепцию CAPI – Coalesced Authority, Power, Influence. Authority – это формальное право говорить "да" или "нет". Power – возможность поощрять или наказывать. Influence – способность убеждать без принуждения. Чтобы изменение реально случилось, нужно собрать все три компонента. Можно быть правым и иметь лучшее решение – но если нет полномочий, власти или влияния, ничего не произойдёт.

Менеджерская результативность – это по сути способность собрать нужный CAPI под свои задачи.

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

#books

Продолжая разговор о книге Адизеса хочется еще поделиться парочкой цитат, которые выписал, пока читал книгу.

Если в ответ на ваше предложение босс говорит "нет", спросите, имеет ли он право говорить "да". Если ему не позволено говорить "да", то выясните, кто обладает этим правом. Только этот человек и должен иметь право говорить "нет"

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

Всякий раз, не соглашаясь с собеседником, уделяйте больше внимания тому, как вы выражаете несогласие, а не тому, что составляет его суть

Очень часто это вижу и проговариваю с теми, кто приходит посоветоваться. Будь ты хоть миллион раз прав – если был агрессивен, раздражен или токсичен, тебя уже не будут слушать. Будут цепляться за форму, а не за содержание. Поэтому очень важно следить за тем, как ты доносишь свою точку зрения.

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

Проблема новоиспеченных тимлидов, которых поставили, нагрузили обязанностями, а вот про полномочия и власть – забыли. Кого нанимать? Не твое. Решение о премии? Не твое. Приоритеты менять? Согласуй сначала. Еще что-то хочешь внедрить – тоже согласуй. И вот у тебя куча обязанностей, а полномочий и власти – нет.

#books

Пятничное развлекательное

Из каждого утюга появляются фреймворки с идеей: поручил задачу агенту – и он пошёл её делать под ключ, используя кучу инструментов и саб-агентов, пока не сделает. Я такие штуки периодически тестирую.

Результат можете посмотреть на картинке 😬

Мультиагенты – может не надо?

Сейчас мультиагентность – одна из самых горячих тем. Фреймворки, оркестраторы, архитектуры с несколькими взаимодействующими агентами.

И вот Anthropic выпустили статью, которая мне очень зашла. Потому что мне кажется они достаточно критично подошли к вопросу – по-инженерному. Не нужно городить мультиагентность, пока не убедились, что она вам реально нужна.

Ребята говорят, что видели, как команды месяцами строят сложные мультиагентные архитектуры – а потом выясняется, что улучшенный промпт на одном агенте даёт тот же результат.

Важно также понимать цену вопроса: по оценкам Anthropic, такие системы потребляют в 3-10 раз больше токенов. Контекст дублируется между агентами, добавляются координационные сообщения, результаты нужно резюмировать при передаче.

Когда действительно есть смысл
– Много лишнего контекста. Когда подзадача генерирует тысячи токенов, из которых нужна пара строк. Отдельный агент отработает в чистом контексте и вернёт только релевантное.

– Задачи можно параллелить. Исследование нескольких источников, тестирование разных компонентов, проверка независимых гипотез. В подобных задачах мало общего контекста. Тут важно, что параллельность — это не про скорость, а про тщательность. Токенов потратится больше, зато покрытие будет полнее.

– Специализация улучшает выбор инструментов. Агент с 20+ тулами начинает путаться. Разделение по контексту использования снижает ошибки.

Как делить
Интуитивно хочется разделить по ролям: один планирует, другой реализует бекенд, третий фронтенд, и ещё один пишет тесты. Но это создаёт эффект испорченного телефона – на каждой передаче теряется контекст и нюансы.

Anthropic предлагают другой принцип: группировать по требуемому контексту, а не по типу работы. Если двум задачам нужна одна и та же информация – пусть их делает один агент. Если задаче нужен изолированный контекст – можно вынести в отдельного.

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

Нюанс из практики: без явных инструкций агент склонен объявлять успех после пары поверхностных проверок. Поэтому верификатору важно чётко прописать, что именно проверять.

Такой паттерн применяется в spec-kit. Там после формирования плана запускается отдельная проверка на соответствие критериям.

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

#ai

Влияние AI-агентов на обучение в разработке

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

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

По скорости группа с AI закончила всего на 2 минуты быстрее, эта разница статистически незначима – то есть выигрыша на этой задаче не было. А вот по тесту разница уже ощутимая: 50% у группы с AI против 67% у контрольной. Разница 17 процентных пунктов.

Самый большой разрыв оказался именно в отладке – способности находить и диагностировать ошибки. И это логично: группа без AI сама натыкалась на баги и сама их разруливала, а с AI этот этап просто пропускался.

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

Те, кто показал слабые результаты, делегировали агенту почти всё: полная автоматизация с самого начала, постепенное сползание от вопросов к "сделай за меня", или отладка через агента вместо самостоятельного разбора.

А у тех, кто показал хорошие результаты, паттерны другие: генерировали код, но потом сами его ревьюили и спрашивали "почему так", просили код сразу с объяснениями и изучали, или вообще задавали только концептуальные вопросы, а код и баги разбирали сами.

Отсюда напрашивается гипотеза: AI усиливает продуктивность там, где знания уже есть, но тормозит формирование новых. Ты быстрее закрываешь задачу – но не особо усваиваешь, что было сделано.

Считаю здорово, что такие исследования появляются, но ребята сами говорят, что это просто капля в море – ещё очень много белых пятен, которые необходимо исследовать.

Но, друзья, от этого и особенно интересно, не так ли?

#ai

Стратоплан CTO: 5 занятий спустя

Прошло 5 занятий по специальности СТО в Стратоплане, делюсь промежуточными впечатлениями. (начало тут)

Каждое занятие состоит из лекционной и практической частей.

Лекции. Тут всё зависит от лектора. В теории обычно всё понятно: вот так проводи 1-on-1, вот так делай стратегию, вот так управляй ожиданиями. Но когда сталкиваешься с этим на практике – узнаешь много нюансов и подводных камней.

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

Практика – это тот аспект, который мне особенно нравится. После прослушивания теории даётся кейс, который необходимо решить. Сначала ты его обдумываешь индивидуально, а потом всех распределяют по группам и вы в группе обсуждаете решение. Я бы сказал, что групповое обсуждение кейса – это самое ценное. Когда ты с квалифицированными ребятами обсуждаешь кейс, и люди делятся решениями, которые тебе не пришли в голову – это прям круто. Только ради этого стоит приходить 🙂

Продукт на миллион строк кода – и ни одной написанной человеком

Как же быстро меняется сфера разработки. Помню, как в начале 2024 года начал разрабатывать с использованием LLM. Тогда ещё не было никаких агентов, не было и расширений для сред разработки. Был обычный чат. Копируешь код из чата, вставляешь в проект, руками правишь. Но уже тогда мне казалось это чудом чудесным.

Ещё буквально полгода назад помню скепсис вокруг агентской движухи. И вот мы находимся в точке, когда целые продукты разрабатываются полностью агентами.

Прочитал отличную статью от OpenAI – где ребята делятся опытом разработки внутреннего продукта только с использованием агентов. Три инженера, ~1500 пулл-реквестов, порядка миллиона строк кода. Ноль строк ручного кода.

Роль инженера сместилась
Я давно уже об этом думаю, и это подтверждается. Работа разработчика становится другой: понимание бизнеса, того, как что должно работать, и создание условий, в которых агент сможет эффективно работать. Когда что-то ломалось, ребята не просили агента «попробовать ещё раз» – а шли разбираться, какой возможности ему не хватает.

От написания кода – к проверке работоспособности
В какой-то момент ребята упёрлись не в генерацию кода, а в проверку того, что он работает. И начали строить автономный луп – подключили Chrome DevTools, чтобы агент сам проверял UI через DOM-снапшоты и скриншоты. Подняли локальный стек метрик и логов, чтобы агент мог полностью отслеживать происходящее.

Документация стала критичной
Первым подходом было запихнуть все инструкции в один большой AGENTS.md. Предсказуемо не сработало – контекст дефицитный ресурс, и когда важно всё, важно ничего.

Рабочий подход оказался такой: короткий AGENTS.md (~100 строк) работает как оглавление с указателями на документацию в репозитории. Дизайн-доки, архитектура, планы, технический долг – всё версионировано и лежит рядом с кодом.

Вообще интересно, насколько возросла важность документации – и даже больше: актуальной документации. Когда мы разрабатывали агента, по нашим замерам явно видели – качество работы агента падает, если документация устаревшая. В OpenAI пришли к тому же выводу и сделали отдельного агента, который регулярно сканирует документацию на устаревшие фрагменты и открывает PR на исправление. По сути – CI для документации.

Архитектурные ограничения
Жёсткая слоистая архитектура, строгие границы зависимостей, кастомные линтеры – всё то, что обычно откладывают. С агентами это стало необходимостью с первого дня. Ограничения – это то, что позволяет агентам двигаться быстро и не разваливать кодовую базу.

Сборка мусора для техдолга
Когда генерируется столько кода, агент воспроизводит паттерны, которые уже есть в репозитории – включая неудачные. Сначала команда тратила каждую пятницу на ручную чистку AI slop – дублирующиеся хелперы, невалидированные данные, расползающиеся паттерны. Такой подход не масштабировался.
В итоге поставили фоновые задачи – агент регулярно сканирует репозиторий, ищет отклонения от заданных архитектурных правил и делает исправления. По сути – непрерывная сборка мусора для кодовой базы.

#ai

Ютуб подсунул любопытное видео.

Сейчас в области AI накопилась куча терминов – LLM, RAG, Embeddings, Guardrails и ещё много всякого. Ребята попытались разложить всё это в одну удобную табличку, чтобы навести порядок в голове.

Посмотрел с удовольствием. А видео в начале поста – для поднятия настроения :)

#ai

Заходите – будет интересно

Когда плотно работаешь в какой-то области, всегда интересно подсмотреть – а как делают другие? Что у них там интересного происходит?

Ребята уже второй раз организовывают митап AI Dev Day. Главная идея – поделиться опытом, как AI-инструменты внедряются в процесс разработки.

Мне особенно интересно послушать, как в других компаниях разрабатывают кодовых ассистентов. И еще тема, которая цепляет – опыт внедрения метрик для оценки AI в цикле разработки. Как это делать правильно – кажется, никто еще не знает.

Ну а я поделюсь нашим опытом: как мы развиваем агента для разработчиков в IDE. Как продвигаем инструмент внутри компании и растим адопшен. Отдельно расскажу про агента за пределами IDE на примере YQL-агента – как адаптировать к внутреннему домену, как оценивать качество и где брать для этого данные.

Мероприятие пройдёт 15 марта офлайн, но будет онлайн-трансляция. Регистрируйтесь, приходите, буду рад пообщаться.

#devfm #ai

Куда податься начинающим разработчикам

Часто дискутирую на тему, как AI влияет на начинающих разработчиков и как правильно учиться в новых реалиях.

Прочитал приятную статью от создателя htmx – стоит ли сейчас идти в разработчики? Автор говорит: да, и делится своими мыслями.

Первое, о чем говорит автор – нужно самостоятельно писать код. Полностью разделяю эту мысль. Если не писать код, то и читать его не будешь уметь. А во времена AI умение читать код становится ещё более важным навыком. Более того, когда не умеешь писать код – у тебя нет понимания, как делать правильно. В итоге просто не сможешь контролировать то, что разрабатываешь.

При этом AI может быть очень полезен для начинающих. Раньше можно было надолго закопаться в проблеме, даже не зная с какой стороны зайти. AI как раз может помочь – не генерировать за тебя, а подсказать направление. Автор приводит пример AGENTS.md – инструкцию для агента, после которой тот помогает разбираться, а не просто генерирует готовый код.

А вот какие навыки будут важны.

Коммуникативные навыки. С агентом, с людьми, письменная и устная.

Понимание бизнес-домена. Тут понравилась забавная мысль. Со стороны бизнеса сейчас порой слышим: всё, нам не нужны разработчики. Автор немного хихикает: это нам, разработчикам, теперь не нужны люди от бизнеса :)

А если серьезно, то я думаю спрос на разработчиков будет только расти. Мы уже не первый раз проходим подобное: 4GL-языки, визуальное программирование, nocode-платформы. Каждый раз слышали, что теперь-то разработчики не нужны, и каждый раз оказывалось, что нужны и даже больше, чем раньше.

Архитектурные навыки. Но навыки не тех архитекторов, которые не пишут код и считают себя архитекторами, а тот навык проектирования, который со временем появляется у разработчика.

А завершается статья вопросом, как джунам находить работу. Автор считает, что пробиваться через сайты подбора – скорее лотерея. И советует старое доброе: семья, друзья, друзья друзей. Пока читал эту часть статьи подумалось, что еще хорошо могут работать стажировки. Когда компании целенаправленно ищут начинающих инженеров и дают возможность развиваться на настоящих боевых задачах. У нас, например, в Яндексе сейчас идёт набор на стажировки по большому количеству направлений.

В общем, выдыхаем – разработчики всё так же будут нужны.

#ai