По аналогии с афоризмом “в ходе следствия главное - не выйти на самих себя”, могу сказать, что в ходе разработки фреймворка для AI кодогенерации удалось сделать сам фреймворк совершенно непригодным для генерации. Например, вчера Claude предложил дописать примерно такое:

with HandlerTestTaskNode.run(**params) as ctx:
    result = solve(lambda ctx: type('TypeContext', (), {'compiler': ctx.compiler})())

Старый приятель @peopleintech показал the best scam ever: приложение с гороскопами и прочей эзотерической мутью, а под капотом на самом деле - AI и когнитивно-поведенческая терапия. Надеюсь, в качестве дефолтной LLM там Gemini ♊

Вообще, на первый взгляд это смешно, а если задуматься, то такой UX не может не быть успешнее, чем стандартный чат-интерфейс с дополнительной парой кнопок поверх LLM API 🤔

Вчера запекал баранью лопатку (вам же интересно мое чревоугодие? 🍖), и из этого вырос пост про случайность и скапулимантию.

Мы все знаем много алгоритмов, в которых случайность важна - в криптографии, оптимизации, ML, распределенных системах и так далее. А как насчет менее академических, более древних примеров? Теория вероятностей стартовала как прикладной инструмент для азартных игр, но я сейчас не про то, как Кардано играл в кости. Но кости в этом тексте еще будут упомянуты!

Давайте представим такую ситуацию: на некой территории живут племя охотников и стая вкусных животных (например, оленей или баранов). Охотники могут отходить от лагеря в поисках дичи в выбранном ими направлении. Олени хотят где-то пастись и избегать охотников. Предположим, что качество пастбищ на всей территории одинаковое. Каково оптимальное поведение для каждой группы с точки зрения базовой теории игр?

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

Например, гадание на лопатке. Алгоритм такой: охотник берет кость нужного зверя, нагревает на углях до образования трещин и трактует эти трещины как своего рода карту, выбирая направление для охоты. Поздравляю, теперь вы знаете, что ответить на интервью, если вас попросят задизайнить random number generator, имея остатки ужина и костер!

Фактоид честно украден из книги Джозефа Хенрика.

Про вайбкодинг

Я сжег уже больше 100М токенов в Claude Code, потому имею моральное право поделиться опытом про вайбкодинг.

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

Не надо применять:
- нетривиальный алгоритмический код (сломается в корнеркейсе - задолбаешься дебажить);
- свежие библиотеки (даже если заставлять читать документацию из интернета, в среднем получается плохо);
- метапрограммирование, написание фреймворков, дизайн API между компонентами;
- security-sensitive задачи.

Надо применять:
- +1 задачи (посмотри, как сделано здесь, и сделай по аналогии);
- все некритичные задачи в незнакомом домене (набросать фронтенд);
- типичный IO layer (в основном хендлеры);
- задачи, в которых вся “сложность” - знать 100500 команд и флагов API (например, aws cli).

2. Вайбкодинг несет неочевидный оверхед в сеньорной команде. Раньше если человек видел код и не понимал его с первой попытки, применялась презумпция качественного кода: если оно написано и закоммичено умным человеком, то, наверное, в этом смысл, надо перечитать и вдуматься. Сейчас иногда приходится переспрашивать “в этом есть какой-то нетривиальный замысел или ты просто нагенерил говна?”

3. Всегда нужно останавливаться и рефакторить - что-то руками, что-то и вайбкодом (“остановись и посмотри, что ты нахуевертил”). Вайбкодинг приводит к куче лишних сущностей, надо вовремя подрезать.

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

5. Главный кайф не только в кодогенерации, а именно в активном агентском режиме - кидаешь промпт типа “посмотри на CI, почему упал такой-то PR и найди проблему” или “я задеплоил сервис этим терраформом, посмотри все логи и разберись, почему хелсчеки не проходят”.

6. Для эффективной работы нужно дописывать правила в CLAUDE.md (.cursorrules и так далее), подключать релевантные MCP и в целом анализировать, где оно косячит. Например, вот кусок моего глобал конфига:

Python style guide:
1) when catching exceptions, use logger.exception("message"), not logger.error(str(e)).
2) do not use mocks unless explicitly asked!
3) ensure types are correct, e.g. def hello(name: str = None) is WRONG, def hello(name: str | None = None) is correct.
4) use logger = logging.getLogger(__name__) when declaring a logger
5) prefer match + case over if + elif + else
6) using hasattr is typically a sign of bad design!

Делитесь своими лучшими практиками в комментах! Просто ворчать, что вайбкодинг - херня для кретинов, можно тоже там.

Szanowni Państwo! Специально для дорогих читателей из 🇵🇱🥟 - разыгрываем три печатные копии книги по ML System Design. Для дорогих читателей из других стран - только промокод на скидку 50% (потому что я слишком ленив возиться с международной доставкой, сорри!).

Как недооценить на порядок тривиальную задачу

Есть небольшая кодовая база; в ней много вызовов LLM. Хочется гонять интеграционные тесты быстро, не ждать ответа от медленной (да и не самой дешевой) апишки. Решение напрашивается: давайте закэшируем ответы (VCR testing)! Это же должно делаться буквально одним кэширующим декоратором поверх уже существующего LLM клиента, не так ли?

Оказывается, не совсем, ведь:
- клиент инициализируется в куче мест, нужно сделать синглтон;
- клиент инициализируется со слегка разными параметрами, нужно привести к общему знаменателю и проверить, что нет регрессий;
- два одинаковых запроса к LLM могут вернуть разные ответы, в т.ч., например, один валидный и один невалидный примерно в одно и то же время.
- клиент вызывается конкурентно и асинхронно, нужен лок;
- запрос содержит сложные иерархические слаботипизированные структуры, вычисление ключа кэширования нетривиально;
- эквивалентные запросы могут осуществляться по-разному (например, через именованные и неименованные параметры);
- часть запроса формируется из логов, а потому может содержать случайные элементы (например, айдишки или таймстемпы), которые нужно подчищать;
- такой VCR кэш устаревает с каждым минимальным изменением в логике того, как мы работаем с контекстом - нужно обеспечить простой и понятный developer experience, как этим пользоваться, как обновить, и в каких случаях это уместно.
- разрастается логика: оказывается трех режимов (не использовать / обновить кэш / проиграть из кэша), не хватает - например, в дебаге полезно иметь гибрид, который и переиспользует старые записи, и может сходить в апишку. А вот для тестов это харам, cache miss должен явно ронять тест.

Но разве кого-то волнует, насколько я недооценил сложность изначально, когда тесты такие быстрые?.. 🚀

Недавно собрал на коленке Reddit Research - максимально простую вариацию на тему deep research, но с фокусом только на реддит (лично у меня это довольно частый сценарий использования и в обычном поиске, и в AI-ассистентах).

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

"Мама, я в телевизоре!"

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

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

В этот раз идеально совпали дождливые выходные и приехавший ко мне Argon EON Pi NAS.

В итоге:
- стряхнул пыль с raspberry, собрал старые диски по всей квартире (получилось 17 с небольшим терабайт) и запихал все в новый корпус. EON классный, все работает, выглядит изящно, всем рекомендую, отличный подарок умеренным нердам.
- поставил openmediavault, долго плевался от того, какой это инвазивный отстой, и полчаса удалял метастазы;
- засетапил там samba и подключил TimeMachine бэкапы (да, так можно!);
- наконец-то засетапил подаренный jetson (как всегда с nvidia, это оказалась слегка нетривиальная задача - нужно замыкать пины, перепрошивать, переписывать конфиги для sdkmanager…). qwen3:8b выдает 7 токенов в секунду, как будто мне это хоть когда-то понадобится;
- связал все это в одну сеть через tailscale, раскидал по углам, умиротворенно слушаю, как шуршат старые HDD.

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

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

Метафора прикольная и, конечно, греющая душу (пусть в старкрафте я нуб, но свои сотни часов в warcraft 3 и age of empires отыграл). Но если обобщать опыт вайбкодинга, то метафора неточная, и Dungeon Keeper или Tropico будут ближе. В классических RTS много микроконтроля: закайтить, отвести раненого юнита, минимизировать урон от AoE; именно микроконтроль отличал казуалов от продвинутых.

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

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

Поэтому символично, что сегодня успели зарелизить app.build - продукт, над которым мы небольшой командой работали с февраля. Это just another end2end генератор CRUD веб-приложений от промпта до деплоя.

Он полностью опенсорсный (можно покопаться в истории и увидеть все мои коммиты в стиле “maybe fix a lot of things”), работает как CLI и обычно генерит скорее работающие приложения. Можно сгенерить на наших серверах, можно развернуть у себя (все равно понадобится gemini и claude API, но можете прислать PR с поддержкой любимого LLM-провайдера). Шероховатостей еще много, но уже скорее работает, чем нет, так что пробуйте и присылайте баг-репорты!

Когда-то давно я нахваливал Streamlit, в свое время наделал на нем пару десятков приложений, и пересадил на него кучу коллег. Но настало время двигаться дальше, и потому сегодня хочу порекомендовать читателям NiceGUI.

Вкатиться в NiceGUI немного сложнее, чем в Streamlit: невозможно просто прокатиться мордой по клавиатуре и получить работающее приложение. Но если повозиться чуть больше, то результат получается сильно более зрелым:
- настоящие отдельные фронтенд (Vue/Quasar + Tailwind) и бэкенд (Fastapi), в которые можно провалиться для доработки (а можно и не вникать и оставаться в высокоуровневом python коде);
- вебсокеты вместо перезапуска всего приложения на каждый чих;
- нормальная поддержка нескольких параллельных пользователей благодаря нескольким гранулярным видам хранения стейта вместо одного st.session_state;
- к этому можно писать тесты!

Вайбкодить на NiceGUI сложнее, чем на стримлите, но мы над этим работаем 👀

Этот пост не имеет никакого отношения к тому, что Streamlit уже давно часть Snowflake, а я сейчас работаю в Databricks.

У меня есть кореша и немного даже собутыльники, которые когда-то стояли у истоков Vochi, успешно продали их Пинтересту, и вот сейчас они запустили новую компанию про genAI и музыку. По этому поводу они ищут толкового deep learning инженера, который умеет не только склеивать апишки, но еще помнит, как пользоваться пайторчем, умеет читать статьи и привносить какую-то новизну поверх - иными словами, повидал некоторое дерьмо может запилить что-то нетривиальное.

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

Сегодня я узнал, что если придти на митап Snowflake❄️ в футболке Databricks🧱, то примерно через час к тебе вежливо подойдут специально обученные люди и попросят уйти

Написал лонгрид о том, как мы делали app.build, какие дизайн-решения принимали и немного о будущих планах.

Рекомендую тем, кто делает агентские системы, и особенно - близкие к кодогенерации.

По мотивам этого поста, запилил бота @ScratchAuthorEgoBot, который умеет почесывать эго авторам телеграм-каналов.

На вход - название канала, на выходе - один из трех видов LLM-based анализа автора (личный/профессиональный/насмешка) по его поста.

Под капотом Rust/Gemini/Neon, и даже прикрутил микроплатежи ⭐️ (первый запрос бесплатно). Больше всего провозился с экранированием и форматированием, потому что telegram API и его markdown довольно особенные.

Через недельку выложу исходники и расскажу, сколько звезд намайнил!

UPD: Уткнулся в лимиты телеграма, все аккаунты, используемые для парсинга, были забанены :(

UPD2: Медленно оживаем, но возможны долгое ожидание и потерянные запросы.

UPD3: В целом все снова работает

Я обещал написать про бота, и добрался только сейчас, потому что этот пет проект вырвался из клетки и чуть меня не сожрал. Было интересно, неожиданный end-to-end опыт от идеи до багфиксов на проде за жалкие три дня.

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

Во-первых, парсить телеграм-каналы через bot API нельзя, и потому я парсил через телеграм-клиент, используя собственный основной аккаунт. Когда набежала толпа пользователей, я быстро попал в софт бан, и начал искать обходные пути. Рынок серых аккаунтов оказался недружелюбным, да и банились они примерно за 10 минут, даже если купить премиум и не наглеть с частотой запросов. Даже удивительно: спам-боты в комментариях прекрасно живут, а довольно безобидное чтение каналов оказалось жестко ограничено. В итоге помог рабоче-крестьянский подход - скрапить веб-версию.

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

В-третьих, к слове о базе данных, я впервые всерьез попробовал Neon (ссылка накинет 5 баксов на аккаунт) для своего проекта и остался очень доволен - все просто работало безо всякой возни, причем на обычном бесплатном аккаунте, это сэкономило мне кучу времени и сил. Всем рекомендую, коллегам респект!

В-четвертых, я впервые что-то сделал end-to-end на расте, и моя жизнь не будет прежней. Писать на нем руками, конечно, сложнее и дольше (skill issue, признаю), чем на каком-нибудь питоне, но если 90+% кода написано агентом, то эта проблема в целом уходит. Зато качество изменилось всерьез: если что-то компилировалось без ворнингов, то оно обычно просто работало. В питоне пришлось бы потратить на порядок больше усилий на тестирование и бесконечные фиксы. Короче, думаю, что всерьез перейду на Rust для одноразовых проектов на выброс. Отдельный кайф наблюдать, как что-то помещается в <40 мегабайт памяти.

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

Статистика: 7500+ юзеров, 200+ плательщиков. Заработано в звездах на ~10% больше, чем потрачено на Gemini API (то есть если бы это был настоящий бизнес, экономика бы едва сошлась; не будь лимитов и платных фичей - я бы наверняка офигел от затрат). Какой-то моментум есть, можно попробовать пилить новые фичи и вообще развивать эту штуку. Для самых любопытных выложил исходники - с нуля я бы сейчас делал слегка иначе (например, надо было использовать каналы, с самого начала делать персистентность для in flight тасков), ну да как есть.

Как и обещал, выкатили поддержку генерации NiceGUI приложений в app.build. По-прежнему бесплатно в managed service и полностью опенсорс.

Продолжаю подрабатывать копирайтером: Six Principles for Production AI Agents.

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

Новость от знакомых фаундеров, которые переобулись в инвесторов: новый фонд Tetrad.vc 📔. Основатели не так давно сами набивали стартаперские синяки — от первых билдов до выхода на глобальные рынки (ZERO10, Wayvee, Sensemitter). Теперь запускают свой фонд и инвестируют на ранних стадиях (pre-seed / seed). Фокус на AI search, agentic AI, гейминг и consumer tech, но в целом открыты к другим нишам.

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

В общем, если вы пилите стартап ранней стадии (а я точно знаю, что среди подписчиков таких немало), присылайте питч или просто познакомьтесь: [email protected]