Markwhen — для построения роадмапов

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

Хочу поделиться гиковским опенсорсным инструментом — Markwhen.

Markwhen позволяет строить роадмапы с использованием синтаксиса Markdown и хранить их в git. Из минусов обнаружил невозможность выставлять зависимости между колбасками.
Вот тут можно потыкать инструмент, посмотреть на его возможности, синтаксис и способы визуализации. А тут документация.

Также у ребят есть всевозможные расширения в том числе для Obsidian и VSCode.

#tools

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

Diagrams

Нравится мне python, а если с его помощью ещё и архитектурные диаграммы рисовать — вообще красота. Поэтому принес ещё один инструмент, позволяющий кодом на питоне создавать архитектурные схемы. В примерах можно посмотреть как это выглядит: тут и тут.

Затащить в полноценное использование командами такой инструмент у меня, конечно, не получится (да и смысла большого нет), но развернуть локально и потыкать интересно. На практике мы используем Structurizer. А ранее у нас был пост, зачем мы документируем архитектуру.

#tools

Life Altering Postgresql Patterns

Постгрю я, конечно, люблю не так сильно, как питон, но всё равно периодически посматриваю на хорошие практики.

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

🔹 UUID вместо автоинкремента — если работаешь с распределёнными системами или API, лучше сразу использовать uuid DEFAULT gen_random_uuid(). Избавит от проблем с конфликтами ID

🔹 created_at / updated_at — каскадное удаление может привести к неожиданным потерям данных. Лучше контролировать процесс вручную

🔹ON DELETE RESTRICT вместо CASCADE — защищает от случайного удаления связанных данных. Лучше удалять вручную при необходимости

🔹Используйте схемы — не нужно всё пихать в public, схемы помогают логически разделить данные

🔹Таблицы вместо ENUM — если нужно хранить фиксированный набор значений, лучше делать это в отдельной таблице. Всегда так делал, а ещё удивляюсь, что иногда енамки хранятся на уровне кода

🔹Таблицы в единственном числе — user вместо users. Логичнее: одна строка = один объект. Хотя наверняка найдутся сторонники другого подхода

🔹Soft delete вместо удаления — автор убеждён, что хранение дешевле, чем восстановление данных, и почти всегда рекомендует soft delete (deleted_at TIMESTAMP NULL)

🔹 JSONB вместо сложных JOIN'ов — удобно для метаданных и настроек, если структура может меняться. Но я бы тут осторожно подходил к такому решению. Например, что будет со старыми данными, если формат json поменяется? А не будет ли проблем с TOAST? На эти темы у нас были отдельные посты: раз, два

🔹Понятные имена join-таблиц — просто объединяйте имена связываемых таблиц и не городите чего-то этакое

#database

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

Давным давно у нас был пятничный пост об идеальном языке программирования DreamBerd.

Прогресс не стоит на месте, один из наших подписчиков поделился ссылкой на интерпретатор для DreamBerd.

Особенно мне понравилась выдержка из документации:

It's worth noting that Github Copilot doesn't understand DreamBerd, which means that Microsoft won't be able to steal your code.
This is great for when you want to keep your open-sourced project closed-source.

#fun

Как я провожу синки с тимлидами

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

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

Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.

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

3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.

Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.

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

О применении ТГ для асинхронной работы была отдельная статья.

#teamwork #devfm

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

Уходящей эпохе Stackoverflow посвящается.

#fun

fd – удобная альтернатива find

Если используете на практике find, то посмотрите на fd.

Работает быстрее, флаги более лаконичные и поведение по умолчанию разумнее. Вот пару примеров:
🔹 fd сам ищет файлы в текущем каталоге (не нужно писать .) и не требует флага -name

fd txt # Найдет все файлы с "txt" в названии

В find пришлось бы писать:

find . -name "*.txt"

🔹по умолчанию игнорирует скрытые файлы. А еще игнорирует то, что у вас лежит в .gitignore. Очень удобно, избавляет от кучи лишних совпадений. В find же нужно указывать

-not -path ‘*/path/*’

🔹можно делать цветной, более наглядный вывод

🔹написан на Rust, ну, сами понимаете – всё работает быстро-быстро 🙂

В ридми у ребят ещё много примеров.

#tools

Про шардирование Postgres и иллюзию ACID

Известно, что шардирование PostgreSQL – задача не из простых. Ребята из YDB в своей статье подсветили один важный нюанс.

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

Это происходит потому что двухфазный коммит даёт только атомарность, а не изоляцию. Распределённый снепшот тут не делается, и гарантии ACID превращаются в AC_D.

В общем, если планируете делать широкие транзакции не забывайте об этом факте.

#database

Оперативный постмит

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

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

Это оказалось супер удобно:
– Сразу видно, что записывается, а участники могут поправить, уточнить, добавить
– Все сразу понимают, кто на ком стоял, кто за что отвечает
– Не нужно тратить время после встречи и что-то дооформлять
– Шаблон постмита позволяет ускорить процесс ещё больше

#devfm

Как проводить встречи эффективно

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

Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂

Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду

Фасилитация
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени

После встречи
– Напиши постмит, опубликуй до конца дня, тегнув участников

#devfm

Советы, как сделать полезный дашборд

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

В статье автор делится советами, как превратить набор красивых графиков в полноценный рабочий инструмент команды.

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

Относитесь к дашборду, как к продукту
– ЦА. Дежурный SRE, разработчик, топ-менеджер?
– CJM. Куда пользователь пойдёт после просмотра? Лог, alert, соседний дашборд?
– Условия использования. Инцидент на ноутбуке, большой монитор в опен-спейсе, недельный отчёт?
– Что улучшилось после изменений. Например, добавил спарклайн -> дежурный быстрее ловит аномалию

Проверяйте на целевой аудитории
Задайте дежурному реальный вопрос («Почему вырос latency?»). Посмотрите, как он ищет ответ. Соберите обратную связь, доработайте.
Показывать дашборд случайным коллегам бесполезно – у них другие задачи.

Правила восприятия
– Читаем сверху вниз, слева направо – важное размещайте в левом верхнем углу.
– Большая панель = важная метрика. Мелкие блоки – второстепенное.
– Цвет привлекает внимание: используйте принцип светофора (красный – критично, желтый – предупреждение, зелёный – норма, синий – справочная инфа, серый – неактивно / неизвестно)

Не перегружайте
– Панель должна умещаться на экране без прокрутки
– Не больше 30 линий на графике. В остальных случаях – top-10 и детальный дашборд по клику
– Не больше 3 типа визуализации на странице – иначе когнитивная нагрузка растёт
– Толщина линий ≥ 2 px – их будет видно даже на созвоне
– Null-значения не соединяйте – разрывы важны для диагностики
– Стекирование используйте аккуратно и делать максимально непрозрачную заливку

Документируйте панели
– Заполняйте Description (поддерживает Markdown)
– Выводите в названии переменные Grafana – сразу видно контекст
– Добавляйте ссылки в настройки панели на инструкции и релевантные дашборды
– Добавляйте легенду и следите за ее читабельностью

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

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

Cursor изнутри
Недавно вышла немного рекламная, но легкая и интересная статья от The Pragmatic Engineer о том, как устроен Cursor узнутри.

В начале статьи просто любопытные цифры о Cursor. Дальше автор рассказывает нам о технологическом стеке. Из интересного:
- TypeScript – бизнес-логика, критические штуки на Rust
- Turbopuffer – основное KV-хранилище, держит зашифрованные файлы + Merkle-деревья для синка
- Pinecone – векторная БД для семантического поиска по коду
- Datadog, PagerDuty, Sentry, Amplitude для обзервабилити
- Linear – для таск трекинга (рекомендую попробовать для тех, кто не пробовал, интересное решение)

Cursor не хранит наш код на своих серверах. Когда вы отправляете запрос в Chat, происходит следующее:
1. Запрос уходит на сервер
2. Сервер решает, что это – вопрос о коде, и запускает векторный поиск по embedding'ам, которые заранее были созданы на сервере во время “индексации” проекта
3. По результатам векторного поиска сервер понимает, какие файлы могут быть релевантны и запрашивает эти конкретные файлы обратно у клиента
4. Клиент шлёт нужные части кода (зашифрованно) – только те, что реально понадобились
5. Сервер “собирает” полный контекст и запускает inference для ответа
6. Ответ возвращается в чат

Отдельно стоит рассказать, как Cursor узнаёт, какие файлы изменились, и переиндексирует только их. Для используются Merkle-деревья:
1. каждый файл разбивается на чанки, каждый чанк хешируется
2. хеши объединяются попарно и формируют узлы следующего уровня
3. в результате строится дерево, корневой хеш которого отражает состояние всего проекта – аналогичное дерево строится и на клиенте, и на сервере

Каждые ~3 минуты клиент сравнивает свой корневой хеш с серверным:
– если хеши совпадают – индекс остаётся прежним
– если отличаются – обход дерева точно выявляет изменённые чанки, и переиндексирует только их

#ai

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

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

В какой-то момент они обратили внимание на ошибки в логах. Вместо обычных снимков нот туда заливали ASCII-табулатуру из ChatGPT. После небольшого расследования выяснилось, что модель советовала пользователям загружать табы в Soundslice для воспроизведения. А самое забавное – то, что такой функции у ребят никогда не было: ChatGPT её просто выдумал.

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

Получилась забавная и немного странная история: фича родилась не из потребностей пользователей, а из-за галлюцинации ChatGPT.

#ai

Насколько AI увеличивает продуктивность программистов

Недавно METR опубликовали исследование с интригующими выводами: авторы задаются вопросом, насколько AI‑асисты действительно ускоряют или замедляют работу опытных разработчиков.

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

Как проходил эксперимент
16 опытных разработчиков из крупных open‑source‑репозиториев (более 22 000 звёзд и 1 млн строк кода) выбрали по 15–20 реальных задач — фиксы багов, новые фичи и рефакторинг. Всего получилось 246 заданий. Каждую задачу случайным образом разрешали выполнять либо с любыми AI‑инструментами, либо без них. Разработчики фиксировали время выполнения каждой задачи.

Ключевой вывод
И вот барабанная дробь: использование AI‑асистов замедляет разработчика на 19%. При этом участники до эксперимента прогнозировали ускорение на 24%, а после всё ещё считали, что AI их реально ускорили.

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

– Ограниченный объём сэмплирования: в бенчмарках модели могут генерировать тысячи вариантов, здесь — лишь несколько
– Крутая кривая обучения: эффект от AI‑инструментов может проявляться после сотен часов практики, а в эксперименте у большинства участников было лишь несколько десятков часов опыта
– Высокие стандарты качества: Open‑source репозитории часто имеют строгие требования к тестам, документации и стилю, что требует дополнительной правки AI‑кода

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

#ai

Опыт применения LLM в разработке

Недавно Сальваторе Санфилиппо, создатель Redis, поделился своим опытом использования LLMок в реальной разработке. Он выделил несколько областей, где AI уже сегодня становится незаменимым помощником:
🔹 Поиск багов и ревью кода. На примере реализации Vector Sets для Redis LLM обнаружили множество ошибок ещё до того, как код попал в продакшен. Хотя мой опыт, и опыт разработчиков вокруг меня говорит об обратном, что LLMки так себе справляются с задачами поиска багов
🔹 Тестирование гипотез. Наколеночные прототипы позволяют быстро проверять гипотезы
🔹 Парное проектирование. Комбинация вашего опыта с энциклопедическими знаниями LLM даёт хороший результат: вы вносите контекст и интуицию, AI – широкий набор паттернов и решений
🔹 Изучение новых технологий. В незнакомой области LLM способны быстро ввести в курс дела и предложить первые рабочие заготовки
🔹 Ускорение написания кода. AI пишет код под вашим чутким руководством:)

Для того, чтобы эти сценарии были действительно рабочими необходимо следовать некоторым правилам:
🔹 В большинстве случаев отказываться от вайб-кодинга. LLMки могут самостоятельно сделать что-то небольшое, но в других случаях получаются портянки неподдерживаемого кода
🔹 Давать максимальный контекст – предоставляйте исходники, документацию, требования и примеры плохих и хороших решений
🔹 Использовать передовые модели для кодинга, автор предлагает Gemini 2.5 PRO и Claude Opus 4
🔹 Послдений совет, который дает автор – не использовать агентов. Он обосновывает это необходимостью контролировать весь процесс. Но по своему опыту могу сказать, что агенты уже достигли того уровня, когда их разные фишечки действительно делают жизнь легче и избавляют от многих лишних действий

#ai

The Impact of Generative AI in Software Development (DORA).

Недавно изучил отчёт (файл) DORA о влиянии AI на разработку. Он большой, поэтому разбиваю выводы на серию постов. Сегодня – первые две главы.

В первой главе авторы приводят цифры и несколько небанальных наблюдений.

Почти все уже в игре: 89% организаций ставят внедрение AI в приоритет, 76% инженеров используют его ежедневно.

Как DORA считает эффект. Они моделируют: если отдельный разработчик увеличивает своё использование AI на 25% (от текущего уровня), как меняются его метрики.

Что выросло: документация +7.5%, качество кода +3.4%, скорость code review +3.1%, скорость аппрува +1.3%, а сложность кода снижается на 1.8%.

А теперь к наблюдениям, которые меня зацепили.

Во‑первых, падает delivery. Throughput уменьшается на 1.5%, Stability – на 7.2%. Логика ожиданий была обратной: раз промежуточные шаги ускорились, значит и поставка должна ускориться. Авторы предполагают, что AI позволяет быстро генерировать большие порции кода, ченджлисты толстеют, и команда нарушает базовый принцип маленьких поставок.

Во‑вторых, просела valuable work. Доля времени, которую разработчики сами относят к valuable work, снижается примерно на 2.6%. При этом на рутинные задачи время почти не меняется, а ощущения flow и продуктивности растут. DORA называет это «вакуумной гипотезой»: AI ускоряет то, что мы считаем ценным, и освободившееся окно забивается тем, что AI пока автоматизирует хуже – митингами, согласованиями, организационным шумом.

Во второй главе авторы пытаются разобраться, что именно разработчики считают valuable work. В итоге получилось пять аспектов. Для каждого описано, как влияет AI и что стоит делать, чтобы влияние было положительным.

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

Репутационная ценность – признание вклада.
AI увеличивает объём результата, но размывает авторство: «это я сделал или модель?». Чтобы перевести баланс в плюс, нужно явно признавать труд по работе с AI – формулировку промптов, проверку вывода, интеграцию – в грейдах и перфоманс‑ревью.

Экономическая ценность – «мне платят за результат».
Эффективность растёт, но вместе с ней поднимается и «новая норма», что рождает страх заменимости. Ответ – смещать оценку на outcomes (что доставлено пользователю), а не на количество строк или часов, и прозрачно объяснять, как AI учитывается в компенсации.

Внутренняя (intrinsic) ценность – важность самого ремесла.
AI обесценивает часть привычных навыков, но открывает новые. Это не минус, а новые вызовы. Нужны время и ресурсы на обучение, чтобы люди ощущали рост, а не эрозию профпригодности.

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

#ai

The Impact of Generative AI in Software Development (DORA)

Продолжаем обзор отчета DORA.

В третьей и четвёртой главах DORA обсуждают доверие к AI и то, как перевести точечные успехи в массовое внедрение.

Сформулируйте понятные правила использования AI
Чётко опишите, что можно и что нельзя: типы задач, работа с данными, допустимые инструменты, требования к проверке и лицензиям. Такая политика снимает страхи, выводит эксперименты из «подполья» и делает применение AI управляемым, а не стихийным.

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

Сделайте обучение с AI частью работы (песочницы, типовые кейсы, наставники)
Опыт рождает доверие. Дайте разработчикам время и формат для практики: внутренние песочницы/репозитории без риска для продакшена, типовые задачи «как мы решаем X с AI», парная работа с наставником, короткие демо‑сессии. Закрепляйте удачные кейсы в мини‑гайдах и общих коллекциях промптов. Чем привычнее инструмент, тем меньше сопротивления и тем выше отдача.

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

Сформируйте видение новой роли разработчика
Далёкий по горизонту, но важный пункт: по мере внедрения AI часть задач заберут инструменты, и роль разработчика будет смещаться. Задайте траекторию трансформации профессии: что автоматизируем, какие навыки наращиваем (проектирование решений, оркестрация и верификация моделей, данные/безопасность), как это отразится в грейдах, обучении и оценке по end-to-end результатам.


В пятой заключительной главе авторы переходят к самому важному – внедрить внедрили, а зачем мы это делали? Мало просто внедрять AI – нужно ещё понимать, насколько хорошо мы это делаем и какие результаты получаем. Для этого нужны метрики.

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

Смысл в том, чтобы связывать использование AI не только с цифрами вроде "сколько подсказок приняли", а с настоящей ценностью: быстрее ли мы поставляем изменения, лучше ли стал код, комфортнее ли работать команде.

А для интересующихся, есть отличное видео от Александра Поломодова, где он с собеседником разбирает отчет за 24 год, в котором DORA делится методами, как все эти циферки вообще получаются.

#ai

Как работать с ai-агентами

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

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

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

Методика автора: решение задачи в три захода

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

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

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

Контекст – ключ к успеху

Каждый ваш разговор с агентом начинается с чистого листа. Чтобы этого избежать, есть свои приемы:

🔹Rules – текстовые файлы с информацией о вашем проекте: архитектурные решения, основные паттерны, любые другие договоренности о правилах разработки

🔹MCP-серверы – очень важно, чтобы агент был интегрирован с вашей инфраструктурой: документация, система ведения тикетов, непродовая БД – со всем, что может дать больше контекста для решения задачи

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

Кстати, автор пользуется Claude Code – отличное решение от Anthropic, рекомендую попробовать.

Попробуйте Context7

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

Для решения этой проблемы есть интересный MCP-сервер – Context7. Этот MCP позволит вашему агенту иметь доступ к актуальной документации огромного количества библиотек. У ребят в ридми подробно описано, как подключить Context7 к вашему любимому агенту.

Расскажите, какие MCPшки у вас в топе?