Будни вайб-кодера (если у вас не так — приходите, научим 😁)

На всех парах готовлюсь к релизу 😁

Опасный тип 😈

Последние дни очень мало сплю, ложусь в 3-4 утра, встаю в 8 и херачу без остановки. Прям даже чувствую, что это уже чуток становится проблемой.
Думаю, скоро вайбкодеры будут приравнены к наркоманам подлежащим лечению 😁 Давно жизнь нам не подгоняла такой дофаминовой иглы. Натуральное казино со всеми признаками.

Че как колитесь, у вас так же или держитесь? Как заставляете себя не залипать поставить очередную тасочку, просто проходя мимо компа в туалет? Давайте, короче, устроим кружок анонимных вайбоманов и поделимся сокровенным.

Заметил такую штуку.

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

Например. Обращаемся к "имени пользователя" . Не нашли? Тогда пусть это будет "Вася" и спокойно идем дальше. И пофиг что никаких Вась у нас нет.

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

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

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

Да, насяльника!

Как вы думаете, что было дальше?

Если вдруг ВНЕЗАПНО исчезнет телеграм и произойдет окукливание, меня можно будет найти тут -> https://max.ru/glebkudr

Я поражаюсь, когда сравнивают агентов по принципу «сколько часов он работал»

Да господи, какая разница? У меня сейчас 95% времени уходит на тестирование нового функционала (ручное, ибо новый) и написание спек. Я совсем не часами агентов ограничен.

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

«Я и моя профессиональная команда агентов-кодеров»

Analysis paralysis у нейросетей

Экспериментальное открытие, возможно будет вам полезным.

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

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

1) Так вот. Если даем таску на 1x, то он делает 1x.
2) Даем среднюю таску (условно 10x) — делает 10x
3) Даем сложную таску (условно 100x) — ожидаем 100x, да?

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

А вот и нет!

На практике качество ответов в какой-то момент начинает резко деградировать. И получается не просто не 100x, но и даже не 10x и даже не 1x.

Я добивался деградации GPT-5 до того, что в ответ он мне предлагал сделать один импорт, и более ничего, из более чем двадцатистраничного ТЗ и суммарного контекста на 100к токенов. То есть формально верный ответ, но катастрофически неполный. При этом интуитивно я ожидал работы на "максимум", пускай и не до конца.

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

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

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

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

PS Эффект получен на чистых промптах через API, в готовых инструментах вы вряд ли до этого дойдете, т.к. там есть встроенные механизмы для декомпозиции задач.

Я проанализировал задачу пользователя: он использует модель из OpenRouter (x-ai/grok-4-fast:free) с тегом override model selection. В логе видны строки о 'display gemini', что вызывает confusion. Замысел: если указана модель из OpenRouter и есть override, то использовать строго её, без fallback. Из кода llm_service.py видно, что для OpenRouter enforced no fallback (models_to_try[:1]), но mapping (_map_model_for_openrouter) вызывается для primary и fallback моделей в resolve_policy и при построении списка, поэтому логи о gemini (fallback) появляются, но фактически используется только overridden модель (grok). Генерация идёт с grok, как и задумано. Нет бага, но логи misleading. Для полного анализа достаточно предоставленных файлов.

Grok-4-fast

Вроде как по сути и не придраться, а вроде как написано чуть-чуть confusing. Не тот фабрик, не тот fashion.

Что скажете?

Shotgun Pro

Новости такие. На этой неделе приватная альфа. Уже закодил заготовил промо-коды 😎

Потом неделя-две на дошлифовку и выпущу уже в паблик.

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

Минус только один — тяжелый вход, ибо для кодинга нужно сделать хотя бы один скан репы. Это еще буду улучшать.

Неплохая вводная статья о состоянии дел в контекстной инженерии https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Подписываюсь под всем вышесказанным.

А все заметили, как AI-кодинг от весеннего "все делаю в курсоре за 20 баксов" переехал в "попадаю на лимиты на подписке за 200"? 🌚

Жестко впахиваю уже неделю (как и два месяца до этого) — делаю релиз шотгана.

Столько всего еще нужно и все приоритетное! 😭

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

Не просите пока тут — для меня важно не вывалить на всех кривую/сырую версию, так что в начале только тем, кто по жизни должен быть толерантен к кривым и сырым версиям 😁

Из интересного.

Делал функционал Repo Folder. Типа, указать у репозитория определенную папку и только ее сканировать.

Ну что может пойти не так? Многое? Вы правы.

Ибо сразу после этого отвалился гит. Причем только на некоторых операциях.

Починить не мог ни курсор ни кодекс. А шотган лежит. Пришлось спешно самому переезжать на стабильный прод 😁

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

Но я вмержил следующую задачку, ну и вы поняли — в 3 часа ночи я все еще сидел с дебагом.

Так и живем 😅

Аналитики — учитесь лить воду!

Задача пользователя:

Это тест. Добавь комментарий в main.py

Агент-архитектор:
— Все понял, начальник!

# Refactoring/Design Plan: Нефункциональный комментарий в backend/app/main.py

## 1. Executive Summary & Goals
- Цель: добавить неоперационный (информационный) комментарий в файл backend/app/main.py без изменения поведения приложения.
- Результат: комментарий на английском, соответствующий правилам репозитория, все тесты проходят.

## 2. Current Situation Analysis
- В backend/app/main.py уже есть модульная строка документации (docstring) и развёрнутая настройка логирования, middleware, маршрутизаторов и lifespan.
- Боль/ограничения: отсутствуют; задача тестовая и не должна влиять на функциональность.

## 3. Proposed Solution / Refactoring Strategy
### 3.1. High-Level Design / Architectural Overview
- Добавить однотипной строкой Python-комментарий в верхней части файла, сразу после существующего docstring, чтобы не влиять на порядок импортов и поведение.
### 3.2. Key Components / Modules
- backend/app/main.py: единственный файл для изменения.
### 3.3. Detailed Action Plan / Phases
- **Phase 1: Minimal, no-op change**
- Objective(s): Вставить комментарий, запустить тесты, убедиться в отсутствии побочных эффектов.
- Priority: High (малый объём, быстрое завершение)
- Task 1.1: Добавить комментарий после существующего модульного docstring
- Rationale/Goal: Выполнить тестовую задачу, не меняя поведение.
- Deliverable/Criteria for Completion: В файле присутствует строка комментария сразу после docstring.
- Текст комментария (на английском, по правилам):
"# Test: Non-functional comment added for demonstration; no runtime impact."
- Task 1.2: Локально прогнать тесты бекенда
- Rationale/Goal: Проверить, что поведение не изменилось.
- Deliverable: Все тесты (pytest) проходят; сборка не падает.
- Task 1.3: Оформить коммит/PR
- Rationale/Goal: Прозрачность изменений.
- Deliverable: Коммит с сообщением типа: "chore(api): add non-functional comment in app.main for test purposes".
### 3.4. Data Model Changes (if applicable)
- Не требуются.
### 3.5. API Design / Interface Changes (if applicable)
- Не требуются. Эндпоинты и контракты без изменений.

## 4. Key Considerations & Risk Mitigation
### 4.1. Technical Risks & Challenges
- Риск: случайная правка docstring или импортов. Митигировать добавлением комментария строго после docstring и без изменения остального кода.
### 4.2. Dependencies
- Нет внешних зависимостей. Только прогон тестов бекенда.
### 4.3. Test design
- Ручная проверка запуска приложения и автоматические тесты (pytest) должны пройти без изменений снапшотов и поведения.
### 4.4. Non-Functional Requirements (NFRs) Addressed
- Maintainability: комментарий информирует о тестовом характере изменения, не усложняя код.
- Reliability/Performance/Security: без влияния.

## 5. Success Metrics / Validation Criteria
- Комментарий присутствует в backend/app/main.py.
- Все существующие тесты проходят без регрессий.
- Нет изменений в ответе /health и других эндпоинтах.

## 6. Assumptions Made
- Допустимо добавлять краткие информационные комментарии в верхнюю часть файла.
- Комментарий должен быть на английском.

## 7. Open Questions / Areas for Further Investigation
- Требуется ли другая формулировка комментария или конкретное место (например, над конкретным блоком логики)? Если да — указать точный текст и позицию.

Менеджер растет 😁

Чпок — добрый воскресный вечер 😁

Продолжается эпопея с альфой. Выходные выдались горячие, потому что у клиентов начали отваливаться коннекшены, а у меня гореть жопа 😂

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

Получил еще тонну фидбэка по UX — как и ожидалось, нужно упрощать процесс.

1) PAT ключи от Github -> перейти на Github Oauth. Чтобы тыкнул по кнопке, выдал репозитории и все заработало.
2) Ключи от LLM -> перейти на использование подписок claude code и других. Тут сложнее, нужно писать десктоп коннектор, но это явно требуется.

Короче, сложно блин делать кодерского агента, скажу вам. Но я настроен добивать 😈

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

На этот раз прикол преподнесла Pydantic AI. Которая как базовый способ аутентификации моделей предлагает патчинг ENV переменных.

Ну а если у вас много клиентов каждый со своим ключом, то что мы будем делать?
Правильно — патчить env на каждый вызов 🌚

Мультитеннатность, изоляция — не, не слышали.

Короче говоря, читайте контракты библиотек, с которыми работаете.

Я знаю, вы хихикаете и думаете — Глеб дурак, а я такого конечно же никогда не допущу.
Желаю вам удач на этом нелегком пути 😁

PS Рефакторил эту заразу аж целый день, корни пустила по всему проекту. Ничего, вычистил по красоте 😎