Год приятной рутины. Спасибо Антон Канев за внимание к деталям и стабилизацию в пространстве.

Не так давно попробовал базовые инструменты проектного управления в работе.

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

На конец года мне прилетела RnD задача.
Было ни хрена не понятно, конкретики минимум, но очень интересно.

Делюсь полезным что мне помогло не провалить поставленную задачу.

1. Сформулируйте цель. Не пожалейте времени и явно напишите ее и осознайте. Мне зашла формула - «Глагол» + что конкретно нужно сделать + «Ограничения». Ограничения это сроки, содержание, стоимость, без них цель это фантазия.
2. Ответьте на вопрос «зачем». Попробуй вписать свою цель в иерархию целей твоей команды или отдела. Пойми что достижение твоей цели сделает для общих целей.
3. Разложи примерные действия которые будешь делать и какой результат ожидаешь от каждого из них. Тут туман в голове уже начнет рассеиваться
4. Напиши критерии успеха заранее. Напиши их так чтобы ты четко мог ответить сделал или нет.

Цель есть, критерии успеха есть. Что делать дальше?

Дальше переводим цель в действия.
Смотрим на критерии успеха и формируем иерархическую структуру работ (ИСР). Декомпозируем проект на понятные шаги.

ИСР отвечает на вопрос:
👉 из каких кусков состоит проект и как они связаны между собой.

Зачем это вообще нужно?

1. Проект перестаёт быть "чёрным ящиком"
Ты начинаешь "есть слона по частям" и вместо абстрактной задачи видишь набор действий.

2. Видишь зависимости между действиями
Когда мы с коллегой работали над одним ИСР (он над бэкендом, я над фронтендом), было проще понять:
• какие задачи я могу начать без него
• где мы можем работать параллельно
• в каком порядке нам вообще разумно это делать

3. Проще договариваться если ты не один
Разговоры между участниками проекта перестают быть абстрактными. Смотрите на конкретные шаги и обсуждаете конкретные действия.

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

Вот такие попытки в проектное управление. Очень приближённо, но это помогало держать задачу под контролем.

Такая только у меня и у… еще двух человек в Авито

Всем привет! Сегодня ровно год как я пришел в Avito Tech. 🎂

Работаю в команде Bricks. Если вам интересны темы BDUI и low code, то рекомендую посмотреть доклады моих коллег.

• Современные подходы к управлению UI: Low Code & Backend Driven UI
• От идеи до UI за 60 секунд
• Beduin Flow: пишем на BDUI по-взрослому
• BDUI от идеи к проду

Это точно со мной происходит? 😀

Я описывал проблему версионности web components в одном SPA вот тут и тут и как ее решал. Там же говорил про Proposal Scoped Custom Element Registries которому уже 7 лет.

Похоже, дело сдвинулось. Safari 26.4 объявил (Web API → Improvements to Scoped Custom Element Registries) об улучшениях поддержки этого API. Chrome поддерживает с версии 146.

Теперь можно создать изолированный реестр и привязать его к Shadow DOM. Каждый shadow root своя версия компонента, без конфликтов с глобальным window.customElements.

Круто!

Такие утренние слоты сильно упрощают рабочий день 💪🏻

Сегодня выступил на внутреннем митапе на работе.

Рассказывал, как верстать разметку внутри платформы, которую мы развиваем.
Давно хотел попробовать выступить. Буду продолжать.

Когда просто LLM поверх доки не взлетает

Думал, что задача «подключить документацию к боту» это просто загрузил документы, настроил поиск, подкрутил промпт и готово.
Оказалось, всё неприятнее.

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

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

Мои промежуточные выводы по такой задаче:
- Prompt engineering помогает, но на корпусе документов из 60 файлов быстро упирается в потолок.
- Если в исходной документации не хватает различий между близкими сущностями, это неизбежно вылезает в ответах.

Без проверки качества такие системы очень сложно «улучшать» вслепую.
В итоге для меня это уже выглядит не как «LLM поверх документации», а как инженерная задача со своим корпусом знаний и проверками.

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

Доверяй, но проверяй.

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

Что происходит при поиске нужного документа в проекте:
- не находит нужный документ;
- находит похожий, но не тот;
- находит правильный, но пропускает важный факт или источник;
- берёт факт из документации, но неправильно формирует ответ.

Для оценки системы собрал небольшой eval: набор вопросов, ожидаемых источников ответов в виде имён файлов и проверок ответа.

Eval состоит из:
- retrieval, проверяет источник ответа и выставляет оценку: попал / не попал;
- judge, другая модель, которая на вход принимает ответ бота и заметки для оценки. Judge выставляет оценку от 0 до 2, где 0 вообще мимо, а 2 точно донёс информацию.

Так стало проще понять не только то, что бот ошибся, но и где именно:
- проблема в поиске;
- проблема в документации;
- проблема в формулировке ответа.

Каждый сгенерированный документ в шапке имеет свой frontmatter, в котором есть информация о том, к какой сущности он относится и какое действие над сущностью описывает.

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

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

AI-assisted engineers are burning out, is this fine?

Мне показалось очень полезным в это время активной агентской разработки.

Примеры прям в точку 🤌🏻

Дождался эту малышку у себя на столе. Ждал два месяца. Nuphy Air 75 V3 😍

Стал чаще слышать о том что AI лаборатории субсидируют подписки и реальная стоимость использования LLM сильно выше того что платим.

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

Посмотрел статистику своего использования Codex за 30 дней. Codex Bar показал примерно 1038$ API стоимости и около 1.4 млрд токенов.

Экспреимент. Подключил локальную Qwen3:32B в Zed Agent.

Сообщение

hello

улетело около 8500 тысячи токенов.

Агентский режим это не только запрос. С ним улетает системный промт, инструкции агента, tools, MCP, скиллы и прочая обвязка.

Получается, что даже на банальном

Сгененрируй commit message

можно потратить десятки тысяч токенов, до того как модель начнет думать. А потом удивляемся, а чего это claude / codex скушал дневной лимит.

Пора начать погружаться в токеномику, пока еще можно учиться на подписках.

Говорят каждый сейчас должен писать свой агентский loop. Мой экспериментальный Software Factory

Claude + cat 🤖🐈‍⬛