axaxadev | Разработка интерфейсов

В рамках оптимизации token spend было принято единственное верное решение — уроки английского два раза в неделю.

Как я ставлю задачи и вообще пользуюсь ИИ-агентами.

у меня нет универсального промпта, идеального набора скиллов и «правильного» воркфлоу.

Я скорее постоянно изучаю, как работаю сам, и подстраиваю агентов под себя.

1. Разделяю исследование, планирование и имплементацию

Для маленьких задач вроде «добавь новое значение в словарик» я просто даю задачу агенту и прошу всё сделать самому.

Но с задачами посложнее стараюсь не начинать сразу с кода.

Сначала исследование.

Например:

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

Агент исследует кодовую базу и собирает мне артефакт.

Новый сеанс:

Мне собрали вот такой документ. Провалидируй его.

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

Получается контекст, на который уже можно опираться.

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

Нам нужно сделать раз-два-три. Вот контекст. Задавай дополнительные вопросы, давай сформулируем план.

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

А вот сама имплементация после этого часто проходит практически без моего вмешательства.

Получается примерно так:

исследование → валидация → план → валидация → имплементация

Технически, конечно, можно сразу сказать агенту: «вот задача, разберись и сделай».

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

И дело даже не столько в сэкономленных токенах.

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

Имплементацию можно делегировать. Ответственность — нет.

2. Изучаю не только агента, но и себя

В Claude Code есть прекрасная команда:

/insights

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

Но интересна мне здесь не сама команда.

Интересно посмотреть на себя как на оператора агента.

Где я регулярно недодаю контекст?

Где слишком рано начинаю имплементацию?

Какие инструкции повторяю из задачи в задачу? (У меня было много разных «стой, подожди, ты делаешь не то»)

Что постоянно приходится исправлять руками?

Что уже стало настолько повторяемым, что его пора автоматизировать?

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

Получается своего рода eval не только для агента, но и для себя.

И я не стремлюсь собрать универсальный набор промптов, MCP и скиллов на все случаи жизни.

Я хочу упрощать свою работу.

3. Не ограничиваюсь написанием кода

Вообще, чем дальше, тем меньше мне интересно использовать ИИ просто как очень быстрый autocomplete.

Агенты помогают мне:

— исследовать незнакомые системы;
— собирать требования;
— искать противоречия в них;
— проектировать решения;
— фиксировать договоренности;
— анализировать смежные системы;
— и только потом писать код.

Работа разработчика сильно шире написания кода.

Поэтому и ИИ мне нужен не только там, где появляется код.

Итого:

не пытайтесь забрать чужой идеальный AI-workflow.

Посмотрите, как работаете вы сами. Где ошибаетесь. Где тратите время. Где повторяетесь. Что хорошо получается именно у вас.

И уже после этого автоматизируйте.

Не адаптируйте свою работу под агента. Адаптируйте агента под свою работу.

люди такие интересные
едут в метро и не знают, что вышел Claude Fable 5.

и не знают..
и едут...

а я знаю, и куда я еду?

"Продакт" потратил все мои токены.

Я тут на выходных решил на агентах Open AI Codex сделать себе команду для разработки всего с помощью paperclip (https://paperclip.ing/)

Это такой оркестратор для агентов, выглядит как таск менеджер + управление агентами.
То есть такая небольшая игра: я владелец, агенты – команда (от CEO до кого угодно).

Начал с небольшого приложения.

У меня была простая задумка: сделать приложение мини-апп для телеграмма (я как релизну поделюсь).

Дальше я нанял CEO, объяснил идею и он начал нанимать команду, выбирать стек и работа потихоньку шла.

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

Приложение на моем стеке писалось. Появилась даже инструкция для меня как это задеплоить (я по инструкции развернул VPS и поднял всё), менялся дизайн, работа кипела и они даже делали то, что мне было нужно.

Потом я подумал, чтобы было бы славно "нанять продакта", скормить ему какой-то крутой скилл, и пусть он доработает проект до вишенки и будем быстрее расти.

Продакт был нанят, не успел я отвернуться, как он сказал, что мы делаем дичь, что нужно реализовывать совсем другое, нагенерировал кучу тикетов, подговорил CEO (тот уже сделегировал всей команде) и эти перцы за полчаса (!) съели всю мою недельную квоту в Codex.

Жду теперь до конца недели, чтобы объяснить, что они не правы.

P.S. Из любопытного, инженер закрывал баг репорты с пометкой "не воспроизводится" и постоянно блокировался об менеджера, чтобы за него приняли какое-то решение.

Когнитивный психолог Шейн Литтрелл разработал Corporate Bullshit Receptivity Scale (CBSR) — инструмент для измерения восприимчивости к бессмысленной, но звучной корпоративной риторике . Он создал генератор корпоративного булшита, выдающий фразы вроде «Мы актуализируем обновлённый уровень аккредитации от колыбели до могилы», и попросил более 1000 офисных работников оценить их «деловую мудрость» наряду с реальными цитатами руководителей Fortune 500 .

Парадокс «вдохновлённых»

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

https://news.cornell.edu/stories/2026/03/workers-who-love-synergizing-paradigms-might-be-bad-their-jobs

На выходных прочитал статью Пола Грэма Taste for Makers.
Удивительно, как и спустя 24 года она по прежнему актуальна.

https://www.ivankapcov.ru/paulgraham/taste/

Она про "красоту" и то, как её распознать, в том числе в программировании.

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

Стать Staff

В предыдущих сериях вы могли наблюдать мой переход от роли тимлида в разработку. Но вернувшись в разработку, вопрос "Куда расти дальше?" никуда не делся. И ответить на него надо было для себя.

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

За годы тимлидства и общения с C-level этот взгляд только укоренился и мне всегда интересно решать именно проблемы, не задачи.

Думая про мой текущий карьерный путь, погружаюсь в то, что нравится делать, что хочу делать и где максимально эффективен.

В роли Senior Frontend Developer мне тесно, в тимлидство возвращаться не хочу. Должен же быть и по мою душу карьерный путь? И он есть – Staff Engineer – это такие лидеры без подчиненных, которые решают проблемы бизнеса и помогают ему добиваться целей.

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

Путь staff-инженера мне нравится, он похож на то, что я делал и хочу делать и это то, где я вижу, как я могу расти. У меня очень сильная "чуйка", что именно нужно делать. Я умею находить больные места, видеть тренды того, куда мы идём, но мне не хватает "умения дожимать", чтобы из локального переходить в организационное.

Несколько примеров для иллюстрации:
• ADR, я внедрил на уровне своей команды практику ADR для фронтенд-решений, это стало стандартом в нашей небольшой грядке. И я остановился и не стал это масштабировать на другие части сервиса, а через полтора-два года у нас появились общие арх-ревью, безумно похожие на то, что делали мы.
• Cycle-time – я был очень обеспокоен тем, как у нас идет доставка фич продукту и внедрял "честный канбан" в своей команде, чтобы иметь представление, как мы работаем, какие у нас узкие места и быть более прогнозируемым, мы отказались от спринтов в пользу борды с приоритетами и классами обслуживания, я следил за метриками cycle-time и находил узкие места. А потом остановился, а через год на уровне сервиса мы стали мерить cycle time и пристально за ним следить.

Среди Staff инженеров есть несколько архетипов, и я сразу узнал себя в одном из них:
• Team lead — растит команду и добивается с ней результата.
• Architect— строит сложные стабильные системы
• Solver— умеет решить любую проблему. Есть продвинутый вариант - Finder → ищет проблемы до их появления. (а вот и я)
• Right hand — «правая рука» директоров: помогает превращать стратегию в технические инициативы

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

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

Хочется растить своё влияние, делать большие вещи, это то, что меня драйвит.
Я на правильном пути.

💚️️️️

Ресёрч — это экспедиция. Не бесконечный поиск.

У меня есть такая черта: когда надо выбрать библиотеку или разобраться в незнакомой теме — я могу уйти в это на часы/дни. Открываю вкладки, читаю доки, смотрю бенчмарки, нахожу статью 2019 года которая противоречит статье 2023 года — и в итоге сижу с десятью открытыми вкладками и нулём решений.

Это не ресёрч. Это туризм.

---

Настоящий ресёрч работает иначе. Я понял это когда наткнулся на концепцию из ТРИЗ — *идеальный конечный результат* (ИКР). Суть простая: прежде чем начать исследование, сформулируй что именно считается ответом. Не «разобраться в теме» — а «принять решение: берём X или пишем своё, и почему».

Без ИКР ресёрч бесконечен. С ИКР — у него есть финиш.

---

Как я теперь работаю с ресёрчем

Перед стартом — три вопроса:

• Что я ищу? (конкретный артефакт: решение, сравнение, понимание механики)
• Когда остановлюсь? (тайм-бокс или критерий достаточности)
• Что будет достаточным ответом? (ИКР)

Это Декарт в применении к задаче — разбирал похожую механику через философию науки. Не принимать ничего за истину пока не проверил, делить сложное на простое.

---

В процессе — фильтр Талеба:

Талеб называет это *skin in the game* — доверяй только тем источникам у которых есть цена ошибки. Автор библиотеки — у него есть (цена ошибки). Автор статьи «топ-10 инструментов 2024» — обычно нет.

Когда читаю доки или статьи — спрашиваю: этот человек деплоил это в прод? У него были последствия, если это не работало?

Это режет шум моментально.

---

На финише — принцип фальсифицируемости (Поппер):

Хорошее решение по итогам ресёрча должно быть опровергаемым. Не «эта библиотека хорошая» — а «берём эту библиотеку, потому что X и Y; откажемся если Z».

Если формулировка не содержит условия отказа — это не вывод, это мнение.

---

Шпаргалка: ресёрч как экспедиция

1) Сформулируй ИКР — что считается найденным
2) Поставь тайм-бокс — 25 минут / 1 час, зависит от веса решения
3) Фильтруй источники по skin in the game
4) Фиксируй находки сразу — не держи в голове
5) На финише: вывод должен содержать условие отказа

Экспедиция без карты и без финишной точки — это просто поход. Можно долго и красиво. Но домой не факт что вернёшься.

TL;DR

- Ресёрч без ИКР — туризм
- Доверяй источникам с ценой ошибки
- Вывод без условия отказа — не вывод

Чтобы не соскучиться, я постоянно работаю над какими-то навыками, иногда это небольшие истории на неделю (вида освоить какой-то инструмент по работате, иногда это один большой фокус на целый год)

В прошлом году основной навык над которым я работал был "Умение дожимать".

У меня есть такая черта, что чем ближе "финал", когда остается совсем чуть-чуть, я плыву:
• теряю интерес
• не могу доделать какой-то важный кусочек
• не могу сделать последний шаг
• начинаю уговоры вида, я основное сделал, остальное "потом".
• теряюсь под давлением, "не умею работать на высоком пульсе"
• считаю сопротивление чем-то ненормальным и хочется как можно скорее прекратить

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

Магия в том, что если в какой-то сфере оно "умение дожимать" начинает получаться, это переносится и на другие сферы. Достаточно в одном преуспеть, чтобы уже поймать волну.

Как я работал над этим навыком?

• регулярный анализ своего поведения (когда что-то "опять" не случилось, анализ, что остановило, чего не хватило и тд)
• выбор одного конкретного объект для "дожимания" – последние пару лет моей целью было пожать 100 кг в жиме лежа (мой образ жизни, работа и всё остальное, не позволяют всё бросить и заниматься исключительно жимом, поэтому это был мой фокус, но и остальное важно было не просыпать)
• кропотливая работа и множество попыток (чтобы научиться работать под давлением, нужно работать под давлением)

Какие результаты?

• 4 декабря мне покорилась сотка в жиме лежа (теперь в приседе + становой + жиме лежа мой макс 310 кг)
• Это начинает влиять на остальные сферы жизни, мне становится сильно легче в работе добивать проекты (я в процессе, но понимание зашкаливает)
• Плинтус еще не добит, но всему своё время.

Дальше закрепляем этот навык и переходим к следующему.
Об этом в следующий раз.

Палеонтология – наука, которая изучает древние формы жизни, их эволюцию и взаимодействие с окружающей средой.

Вроде всё верно

Ничто так не бодрит с утра, как фон 5хх от приложения.

Вчера провел незабываемый день за дебагов падений в проде.
Моё nestjs приложение крашилось, поднималось в облаке и падало вновь.

А виной всему логгирование AxiosError. У меня в одном месте в приложении она передавалась в прямом виде (а это страшная ошибка, там внутри примерно ссылки на все кишки приложения).

Приложение пыталось рекурсивно обойти всю ошибку, чтобы залогировать, упиралось в CPU, память, диск, из последних конвульсий выплевывало в stdout последнего монстра с разными Circular ~.@fields.err.request._options.nativeProtocols.http:.globalAgent.sockets и облако переподнимало под.

И тут на "помощь" приходил балансер.

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

Не логируйте AxiosError и прочие сложные объекты, делайте плоские структуры и записывайте только их.

Всем стабильности!

(Моно)репозитории

Обычный сценарий: один репозиторий = один пакет/сервис.
Сложный сценарий: десятки мелких реп, которые зависят друг от друга и требуют синхронизации.

Монорепа — это один репозиторий, много пакетов и сервисов, единые правила для зависимостей и релизов.

Когда монорепа уместна

- общий стек и общие зависимости
- нужен единый стандарт качества и релизов
- есть связность между пакетами/сервисами
- хочется упростить локальную разработку и интеграцию
- релизы «цепочкой» — норма, а не исключение

Когда монорепа НЕ нужна

- проект маленький и автономный
- релизы независимы и редки
- разный стек, разные команды, разные процессы
- есть жёсткие ограничения по доступам
- нет ресурсов поддерживать дисциплину CI/CD

Подводные камни

1. Линковка пакетов
Без нормальной схемы линковки легко получить «работает только у меня».

2. Установка зависимостей
Чем больше пакетов, тем больше хаоса в node_modules.
Нужны единые версии, lockfile‑политики и дедупликация.

3. Версионирование

- _Fixed_ (все пакеты одной версии) — проще, но тяжелее для частых релизов.
- _Independent_ — гибче, но требует строгих правил и автоматики.

4. CI/CD
Сборка всего на каждый чих = боль.
Нужны инкрементальные сборки, кэширование и селективный запуск — только затронутые пакеты.

5. Границы
Монорепа не должна превращаться в безразмерную свалку.
Нужны чёткие зоны ответственности и правила владения.

Шпаргалка: «как прижечь шею»

1) Определись с правилами:

- единый стиль и линтер;
- единый lockfile;
- единая политика версий.

2) Определи структуру:

- packages/* для пакетов;
- apps/* или services/* для сервисов;
- общий tools/ или scripts/.

3) Настрой релизы:

- changelog‑генерация
- автоматическая публикация
- согласованные теги и правила

4) Ускорь CI:

- кэш зависимостей;
- запуск только затронутых пакетов;
- параллельные задачи.

Личный опыт.

Работал в команде общих компонентов — занимался версионированием и автопубликацией монорепы.

Система контроля версий у нас была не git, поэтому open-source инструменты (все завязаны на git) не подходили. Пришлось писать своё. Здесь пригодилась теория графов: пакеты — узлы, зависимости — рёбра. Чтобы при независимом версионировании не выставить кому-то лишнюю версию, нужна топологическая сортировка.

Для версионирования использовали conventional commits: разработчик прямо в коммите указывает тип изменения (patch/minor/major), дальше автоматика. Просто и предсказуемо.

Если есть вопросы про организацию монорепы — пишите в комментарии.

Выводы

Монорепа — это не магия, а дисциплина.
Она спасает от «двух новых голов на каждую фичу», но требует правил, инструментов и внимательного ухода.
Если головы растут слишком быстро — пора прижигать.

Если хочется больше погружения:
- Гайд от создателей Nx (сами участвуют в сравнении, но материал полезный): https://monorepo.tools/
- Хороший доклад про монорепу от Вовы Гриненко: https://youtu.be/okN-o7BseSg?si=oOIY0qAHuyJIWqfZ
- Conventional commits: https://www.conventionalcommits.org/en/v1.0.0/

Подвиги фронтенд‑разработки — Лернейская гидра

В этом посте Лернейская гидра отвечает за навык управления сложными зависимостями и (моно)репозиториями, когда каждая новая фича отращивает две новые головы в виде пакетов и сервисов.

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

Здесь «новые головы» — это новые репозитории и пакеты, которые разъезжаются кто куда при каждом изменении.
«Прижечь шею» — собрать их в монорепозиторий и ввести нормальные правила версионирования и релизов.

Ключевые слова: пакетные менеджеры, зависимости, репозитории, монорепозитории, система контроля версий, npm, git, lerna, теория графов, conventional commits.

TL;DR

Монорепа — это способ остановить размножение зависимостей и сделать релизы управляемыми.
Но она требует дисциплины: единые правила, CI, версионирование и разумные границы.

## Словарь (в рамках этого поста)

- npm‑пакет — упакованный код для Node.js, распространяемый через реестр npm.
- сервис — программный модуль (веб‑приложение или бэкенд‑сервис), который не публикуется в реестр, а разворачивается в инфраструктуре.
- репозиторий — распределённое хранилище кода: локальные копии + центральный origin. Обычно одному пакету/сервису соответствует один репозиторий.
- CI/CD — набор процессов: тесты, линтинг, сборка, публикация пакета, выкладка сервиса.
- монорепозиторий — один репозиторий для нескольких пакетов и сервисов, с общими правилами работы и релизов.

Подвиги фронтенд‑разработки

Люблю античные мифы и давно хотел притянуть их к разработке. К тому же через ассоциации мы лучше запоминаем сложные вещи. Поэтому запускаю серию постов по мотивам подвигов Геракла для фронтенд‑разработчиков.

Что будет внутри каждого поста:

- короткое напоминание про подвиг;
- какие концепции разработки в нём можно разглядеть;
- байки, примеры и боль;
- шпаргалка с концепциями, рецептами и доп. материалами.

Подвиги:

- Лернейская гидра – (Моно)репозиторий

Мой рабочий 2025 год. На графике коммитов отчетливо видно, когда я стал больше писать код.

Честно говоря, рад возвращению, это то, что мне очень нравится и хорошо получается.

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

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

И кстати, если вы шли сюда с какими-то конкретными ожиданиями, напишите пожалуйста в комментарии. подкручу свой контент план под вас. 👇👇👇

у Cloudflare очередной сбой.
интересно, что на этот раз.

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

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

https://www.perplexity.ai/search/u-menia-est-teoriia-zagovora-c-jevYzRM1QQa28s2FTDvvbw#0