melikhov.dev

Пока готовим CTF 2026 — решил всё сломать задевопсить всё нормально. Там же всё было на палках и rsync, чем больше мы накручивали заданий тем дольше шёл деплой. Конфигурации максимально в ручную, каждый год заново вспоминать, что же там было в прошлом году.

В общем в этом году будет на отдельной vm с терраформами, докерами, флуент бит, клауд логгингом и прочими радостями. А чтобы девопсить было веселей — собрал всё через claude code, такие задачки он на ура делает. Посидел с superpowers побрейнстромил и вперёд

☐ Task 1: Создать базовую структуру Terraform ☐ Task 2: Создать cloud-init конфигурацию ☐ Task 3: Создать основную Terraform конфигурацию (VPC, Subnet, Security Group) ☐ Task 4: Добавить Static IP, Data Disk и Compute Instance в Terraform ☐ Task 5: Создать Terraform outputs ☐ Task 6: Создать Terraform README ☐ Task 7: Создать nginx конфигурацию ☐ Task 8: Создать Fluent Bit конфигурацию ☐ Task 9: Создать обновлённый docker-compose.yml ☐ Task 10: Создать .env.example для docker-compose ☐ Task 11: Создать deployment скрипты ☐ Task 12: Создать Infrastructure README ☐ Task 13: Обновить GitHub Actions workflow ☐ Task 14: Создать документацию по первому деплою ☐ Task 15: Финальная проверка и подготовка к деплою

Сегодня в докладе показывал новый Gravity компонент для AI-чатиков, кажется забыл сказать, что демка с ним лежит за веточкой aikit https://github.com/melikhov-dev/subbotnik-2025-demo/tree/aikit

6 декабря делаем финальный в этом году Я.Субботник по разработке интерфейсов в Петербурге (и онлайн).

Снова буду говорить про работу с AI API. Другие доклады ещё лучше, заходите на огонёк. https://events.yandex.ru/events/ya-subbotnik-2025-12-06

Сидел пилил zod-схемы для DTO и заметил, что нейронка (нейронки! не одна!) упорно пытается работать с zod4 как c zod3, игнорируя новые методы. Это и к вопросу о том, что нейронки могут зацементировать текущее состояние веба — они обучены на массиве кода и продолжат генерировать код, на котором их обучили. Учили на Реакте, значит везде будет Реакт.

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

А вообще zod схемы в shared между фронтом и бэком — это приятно и удобно. Главное не забывать, что DTO должен жить только на границе и не превращать в него модели и половину джунглей в придачу.

ACP в zed оказался не так хорош, как я думал

Ну ладно, пока буду делать claude -r

https://github.com/zed-industries/zed/issues/37481

Эксперименты с апишками заставляют отметить, какое сейчас прекрасное время, чтобы пробовать новое.

Открываю Perplexity (я его уже дефолтным поисковиком поставил, хах), открываю Zed. В одном окне копаю информацию, во втором агент собирает прототипы (мы как-то пропустили смерть классического скаффолдинга).

Можно собрать базовый вариант. Можно усложнить. Можно накинуть тестов и запрофилировать. Можно пообсуждать результаты с нейронкой.

Можно двинуться дальше и спроектировать полноценное приложение, чтобы проверить теорию.

Что мы теряем? Да разве что набитую руку на быстрое создание новых проектов. Есть такое (и ведь я сам не пользуюсь алиасами, чтобы пальцы не забывали как отбивать команды). Но, честно, у меня тут ребенок на одной руке висит, второй я варю суп. А желание проверить идею оно же буравит мозг и спать не даёт.

Я думаю, что мы так или иначе будет всё более верхнеуровнево смотреть на код, освобождая место в памяти от сигнатуры функций, в сторону ревью алгоритмов и концепций и теряя скилл вайтбординга. Да так ли это важно? Вот мне в 40+ уже нет, мне важнее быстро концепции проверять и выбирать лучшие. Зато насмотренность в коде как растёт*!

*Я всё ещё не приемлю вайб-кодинг и вычитываю каждую сгенерированную строчку.

Если на JS, то разве что через переопределения метода fetch у класса работы с ЛЛМ можно законсольложить сформированный запрос. Я на MoscowJS как раз на это жаловался, начиная с 52:32

А если на Python, то там я вообще не нашёл, можно ли это как-то сделать

Попробовал переписать с OpenAI API SDK на LangChain (говорят это база) и... что-то не понял. Абстракции они же должны вроде как сложность скрывать, но сложности в OpenAI Chat Completions API никакой (зря что ли ребята в Open AI потратили всего одни выходные чтобы его создать). А вот приносимой боли в дебаге немало — добраться до того, что там на самом деле происходит будет уже непросто.

Самое смешное, что claude code на вопрос «давай накинем дебага и узнаем, как там залетают в апи тулы» предложил мне просто переписать на OpenAI API SDK, потому что тот объём шума, который вываливает env LANGCHAIN_VERBOSE = "true"; он переварить не способен.

Да, есть LangSmith, но это уже какой-то оверкилл подрубать внешний платный SaaS-сервис для дебага обёртки над простеньким api.

В то же время вызов OpenAI API SDK элементарно превращается в обычный curl запрос, который ты можешь приложить к тикету в саппорт, если сам не разобрался.

Не удалось в короткий тайминг впихнуть всё (плюс пришлось немного спешить). И вот остался на руках у меня почти нераскрытый Responses API, а раскрыть/показать его идеи и противоречия хочется. А там прямо интересно! Многое уже можно попробовать прямо у нас в AI Studio. Хотя и не всё (но обещают довезти тот же Conversations API). И сам бы послушал какого-нибудь фаната Langchain, чтобы он попробовал убедить меня забыть про OpenAI SDK.

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

29 октября на митапе A?.Frontend Community порассуждаю про эволюцию OpenAI API

https://digital.alfabank.ru/events/frontend-b-day-meetup

Тайминг плотный (люблю такое) попробую впихнуть самую суть.

Трансляция будет

Насколько всегда с отвращением пользовался Курсором, настолько же (но в положительную сторону) с удовольствием запускаю задачи в Claude Code. Сложно объяснить это ощущение, но как-то там более лампово и уютно что ли. И результат сильно лучше, особенно после нескольких итераций с ревью в Copilot.

А главное — нет причин менять IDE/редактор. С zed так вообще нативная интеграция из коробки, но всегда можно открыть терминал и сделать там всё.

Удивительно, что пока экстеншены затаскивали векторный поиск и наворачиваи UI, оказалось, что агенту достаточно grep для того, чтобы собрать хороший контекст и sed чтобы поправить код.

Занесло в такую компанию, аккуратно посередине с докладом.

И как удачно, стоило мне пожаловаться, что ещё не добрался попробовать Responses API, как вышел @shwarsico и отрекламировал, что API уже доступен в AI Studio

Так что если вы как и я пока не понимаете, в чём же такие критические преимущества Responses API над Chat Completion API (см на слайд на втором фото), что OpenAI крайне советует на него переходить во всех новых проектах — то уже можно попробовать, в том числе и у нас в Yandex Cloud.

Как тут устать от профессии, когда постоянно подвозят столько нового интересного.

26 сентября буду выступать в Пензе на Secon

Порассуждаю как сейчас делать AI-агентов и почему это нормальная и решаемая задача для фронтендеров. Приходите поспорить.

Тут кажется требует уточнений, что говорить мы будем про UI, который потребляет API LLM.

Пока все стряхивают пыль с читалок, чтобы залить свежего Пелевина, мы вместо этого не спим и готовимся к Neuro Scale. Фиксим ещё один последний баг и выкатываем последнюю_финальную_теперь_точно_финальную_версию (2).

Так уж случилось, что ритм в Облаке годичный, от Скейла до Скейла. Всё, что непосильным трудом наделано — всё покажем.

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

Если первые впечатления от того же Cursor были отвратительными, то сейчас он уже как-то подуспокоился в своём стремлении делать YOLO и может предоставить сравнимый с Roo опыт постепенного продвижения по задаче. При этом, конечно, в более приятном интерфейсе (те же диффы изменений выглядят гораздо наглядней, чем в Roo).

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

В целом и там, и там можно работать с одинаковой эффективностью. А вот вопрос стоимости сложный, понятно, что в чистом виде Cursor будет дешевле, но кто ж знает, к каким моделям у вас есть доступ? У меня вот Roo смотрит в «бесплатный» развёрнутый внутри DeepSeek и платный Claude. Щёлкаю под задачу и наличие денег на счету.

Сама по себе работа в паре с AI (то, что пытались зафорсить как DeepCoding в противовес VibeCoding, но, кажется, не прижилось) неплохо так прокачивает скиллы код-ревью. Я (как типичный IC) редко работаю над кодом в команде, и вот тут второй пилот вернул забытые ощущения и позволяет держать ритм.

Продолжаю радоваться, что дожил до такого.

Обещал же расписать.

Прошу не проецировать на весь Яндекс, так как все бизнес-юниты работают совершенно с разными подходами. Более того, даже внутри одного БЮ может быть разный подход в разных командах.

Так вот, в нашей команде все занимаются почти всем. Да, фронтендера не попросят писать под на Питоне, бэкендера не отправят на Реакт. Но девопс, БД, сеть — такие задачи могут прилететь любому. Если этот любой готов к этому (и это важно). Мы знаем, кто к чему тяготеет, и насильно не отправим человека решать задачи, не свойственные его скиллам.

Т.е. пресловутый t-shape присутствует, и у каждого своя палочка своей конфигурации. Тут задача — удерживать команду в балансе, чтобы всё не упиралось в одного узкого специалиста (а так оно и будет, если вы уйдёте в гипер-специализацию). Два-три человека должны быть в каждой области.

То есть в команде не случайные люди — она собрана исходя из этой специфики изначально. И это работает.

Что нам это даёт? Возможность двигаться быстро. Возможность не ждать, пока узкий специалист освободится/выйдет из отпуска. Возможность привлекать сильных специалистов, которые ищут место, где смогут покачать скиллы в другой области. И даже возможность, пока заняты бэкендеры, собрать «настоящий» бэк на ноде силами фронтов.

Это не плохо и не хорошо, это просто вот такой вот подход, который в наших условиях работает.

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

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

https://datalens.yandex.cloud/?_lang=ru#neuroanalytic

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

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

Вообще конечно все эти AI-агенты просто возвращают мне радость программирования. Машина наконец-то делает то, что должна — скучную рутину. А мы парим над этим и раздаём указания. Проверяем теорию за теорией, собираем пруф оф концепты за нефиг делать и тут же без жалости (икеа-эффекта нет) выкидываем. Делаем за день недельную работу.

Я прямо очень доволен. Старички вроде меня снова в строю и могут поделать архитектурку.

RAG на коленке

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

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

Результат офигенный конечно. Но вот зараза, у меня нет под рукой нейронок для эмбеддинга. Во внешний мир ходить не хочу, проект внутренний. Что же делать, как показать пруф оф концепт? Собираем с Клодом веб-скрейпер на плейрайте, дербаним доку в JSON, кормим этот JSON приложению на ноде, обслуживающему чат. Теперь на каждый запрос пользователя выбираем слова подлинней, лезем в JSON и находим совпадения (ахах, да, можно было бы и морфологию прикрутить, но некогда, работа не ждёт). Собираем промпт по совпадениям и закидываем в LLM вместе с запросом пользователя. И оно работает. Да, неоптимально, чертовски неоптимально. Но для PoC за глаза хватило.

Сидел с утра собирал memory bank в Roo. Потрясающая штука, даже если им не пользоваться (а почему?), но просто почитать — вот он твой проект как на ладони. Но, конечно, нужно покопаться в нём вместе с нейронкой, направить её в правильную сторону.

Это, кстати, причина, почему roo, а не cline. В cline всё как-то победнее (ну это просто связано с меньшим количеством режимов работы агента).

Если кратко, то memory bank это просто папочка со структурированным описанием вашего проекта, на которую вы натравливаете агента через промт (не вручную конечно же, агенты умеют подмешивать промты из конфига).

UPD: Ну и это конечно уже вчерашний день, потому что теперь есть Context Portal MCP 😃 С RAG конечно же.