Вектор диалога с LLM плывёт каждый ход, и к концу разговора персонаж уже не тот. Рассказываю, как я это чиню в своём движке: классификатор выбирает «тег реакции» через constrained decoding, числовые оси отношений двигаются по таблице, а медленные «стадии» задают тон. Всё объяснимо — каждый сдвиг привязан к числам, которые видно в логе.
В начале июля я объявил весь код своего проекта легаси. Не модуль — всё: код, архитектуру, документацию. Месяц до этого проект — джоб‑маркетплейс для синих воротничков: мобильное приложение, web, AI‑ассистент — делала команда. Люди сильные, каждый уже работал с LLM‑агентами; не было другого — методологии работы с агентами. Агент пишет код быстрее человека — и энтропию порождает быстрее: все ветки в main, решения только в чате, документация врёт, персональные данные оседают в access‑логах. Каждый исполнитель локально прав, система в целом не работает. Код, который страшно трогать, появился у нас раньше, чем первый работающий флоу. Я остановил всё и начал заново — один.
Всем привет. Я много лет играю в Counter-Strike и тренируюсь, как большинство: захожу в Deathmatch «размяться», играю три катки, тильтую, выхожу. Сервисы статистики при этом исправно сообщают, что у меня просела точность и выросло время реакции. Спасибо, а делать-то что?
Весной я решил собрать себе тренера сам. Сразу пара слов для контекста: я самоучка, в команде никогда не работал, основной опыт — десктопные утилиты и автоматизация, из веба до этого были только админки под собственные инструменты. В CS тоже звёзд с неба не хватаю, Premier в районе трёх тысяч, на FACEIT вообще первый уровень. Так что история будет не про успешный успех, а про то, где я наступил на грабли и что из этого вынес.
Сам сайт делает вот что: подтягивает историю матчей, отдаёт агрегированную статистику LLM, а та разбирает сильные и слабые места и составляет недельный план тренировок, с конкретными картами, режимами и минутами. Отметил выполненное, сыграл новые матчи — план подстроился.
Проект мой, ссылка будет одна и в конце. Статья состоит из трёх частей: сколько это всё стоит в токенах, где модель выдумывает и как я это ловлю кодом, ну и подводные камни DeepSeek API и связки EF Core + SQLite.
Собрал ассистента встреч, который работает целиком на моём маке: локальный STT, живая диаризация голосов, мгновенные ответы на вопросы собеседника и самообновляемый граф знаний в Obsidian. Внутри — грабли: ловушка обращений при расстановке имён, 23 «голоса» из-за осколков кластеризации, num_ctx и бюджет RAM в Ollama. Код открыт, Apache 2.0.
10 лет в .NET, отпуск в Альпах и pgAdmin, который меня достал.
Начало июля, горный воздух, а в голове рабочая фрустрация. Ну сколько можно ждать по 30 секунд, пока pgAdmin разродится ради одного короткого запроса? Из инструментов с собой только смартфон и лимиты Claude Code. Challenge accepted.
За выходные, целиком с телефона, не написав руками ни единой строчки кода, я собрал первую рабочую версию нативного GUI для PostgreSQL. Дальше две недели вечернего кодинга, 17 релизов, и проект уже в Microsoft Store.
Встречайте: NativeAOT, взлетает за ~100 мс, весит всего 19 МБ, ноль трекеров, лицензия MIT.
Написал об этом подробный пост. Без лишней воды и успешного успеха рассказываю: как агент тащил разработку (от кода до дебага в песочнице) и где ему всё-таки нужна была менторская рука, какие грабли подкинул NativeAOT и как бесплатно выкатиться в Microsoft Store без покупки дорогого Authenticode-сертификата.
Заходите почитать, а в конце проголосуйте в опросе, какую фичу пилить следующей: ER-диаграммы, визуальный дифф EXPLAIN, UI для бэкапов или локальный AI?
За четыре месяца работы в паре с Claude Code вокруг проекта наросла инфраструктура, которой в первый день не было и в помине: пять скиллов, четыре хука, 2066 строк собственных скриптов. Разбираю четыре проблемы, которые пришлось решать не промптом, а кодом — и три случая, когда агент уверенно врал.
AI уже умеет быстро писать отдельные функции, но в большой системе перед изменением нескольких строк агенту приходится читать сотни файлов и заново восстанавливать архитектурный замысел. Увеличение контекста и подробные спецификации помогают, но на масштабе рядом с горой кода может появиться гора документации, которую тоже нужно анализировать и синхронизировать.
В статье я рассматриваю другую возможность: формальное архитектурное представление между намерением и кодом. Типизированный исполняемый граф может одновременно задавать границы для AI, валидировать архитектурные изменения, генерировать сервис и локальные SDD-задачи, а в runtime служить картой наблюдаемости. Это инженерная гипотеза о том, каким может стать интерфейс совместной работы человека и AI.
Всем привет, начиная с прошлого лета я потихоньку клепал свою версию Telegram Wrapped.
Началось всё максимально тупо. Я увидел в TikTok рекламу очередного сервиса, который обещал красиво проанализировать мой Telegram. Проверять такое на основном аккаунте мне показалось сомнительной идеей, поэтому я зашёл туда с фейка, на котором было буквально три переписки.
В итоге фейк угнали.
Да, аккаунт с тремя чатами.
После этого я задумался: почему вообще ради красивой статистики человек должен отдавать кому‑то код входа, сессию Telegram или доступ ко всему аккаунту? Так появилась идея сделать свой Wrapped, который не заходит в аккаунт и не отправляет переписки на чужой сервер.
Я маркетолог и до этого проекта не писала код. Но с помощью GPT собрала рабочую систему сбора, обработки и аналитики отзывов для ресторанной сети: 16 500 отзывов в одном контуре, более 9 500 записей в собственном хранилище, четыре XML-фида, мониторинг, автоответы и 130+ страниц документации. Все это обходится в 8,5К в месяц.
Это кейс не только про AI-assisted development, но и про вполне прикладную пользу для бизнеса: меньше ручной работы, меньше пропусков и ошибок, единая аналитика и понятная стоимость эксплуатации. А заодно – честный разбор того, где AI действительно снижает порог входа в разработку, а где без человеческого контроля быстро начинает моросить.
Мы с братом вдвоём разрабатываем WorkHub. До этого у нас не было профильного образования и опыта создания цифровых продуктов. Мы не работали внутри IT‑команд и не проходили путь от стажёра до разработчика. Возможность начать появилась во многом благодаря ИИ‑инструментам.
Я, в основном, отвечаю за продуктовую документацию, проработку функций и тексты. Код мы пишем вместе. Брат сильнее влияет на общее видение продукта и занимается аналитикой. Жёсткого разделения ролей у нас нет: небольшие UX‑проблемы, разработку и проверку реализации мы часто разбираем совместно.
Как утверждают психологи «все проблемы человека происходят из детства» — все что не дали родители в юном возрасте потом обязательно проявит себя во взрослой жизни.
В моем, весьма специфическом случае такой нереализованной мечтой детства долгое время оставался... компилятор Watcom, дорваться до которого удалось лишь спустя почти тридцать лет.
Рассказываю об этом удивительном проекте.
Вайбкодинг принято ругать за грязный код и отсутствие архитектуры. Но когда цель — быстро проверить гипотезу и сделать яркий MVP для хакатона или конференции, этот подход раскрывается на полную. В этой публикации я разберу свой кейс создания проекта с помощью ИИ, который взял первые места на двух конференциях.
Представьте, что вам нужно обрабатывать десятки тысяч сообщений с помощью LLM: извлекать данные из текста, классифицировать объявления и получать строго структурированный JSON. При этом стоимость каждого запроса должна оставаться минимальной.
Я столкнулся именно с такой задачей и попробовал несколько подходов: от бесплатных моделей до платных API. В итоге удалось снизить стоимость одного запроса примерно до 0.006 рублей, сохранив качество обработки.
В статье расскажу, как я пришёл к этому решению и почему в итоге написал собственный API-слой поверх OpenCode Go.
Все началось с отпуска HR.
Нужно было срочно нанять пару менеджеров, а времени на десятки одинаковых переписок просто не было. Поэтому я написал небольшой Telegram‑бот для первичного отбора кандидатов.
Но каждая решенная проблема открывала следующую. Сначала появились анкеты и скоринг. Затем аналитика, триггерные сообщения, LLM, база знаний и собственный визуальный конструктор сценариев.
Если вы занимаетесь подбором персонала, автоматизируете HR‑процессы или разрабатываете Telegram‑ботов, возможно, мой опыт поможет избежать нескольких ошибок и сэкономить время.
Недавняя статья открыла для меня устройство столь упоро необычное и несущее столь любимый нами трудноуловимый флёр «балдёжности», существование которого раньше проходило мимо меня — NeoGeo. Как говорится, «это не первое моё родео» — на использовании 2D‑ускорителей в качестве 3D‑ускорителей я съел изрядного бобика.
Примерно месяц назад мы сняли видео [а на Хабре опубликовали его перевод] о сложности реализации игры наподобие Doom на консоли Neo Geo. Причина заключается в том, что у Neo Geo нет концепции буфера кадров, то есть всё, что мы видим на экране Neo Geo, рендерится, как спрайт. Также в этом видео я рассуждал о концепции движка рейкастинга, который вполне неплохо работал на Neo Geo. Придуманная мной концепция, по сути, заключалась в создании плоской сетки блоков и испускании одного луча на каждый вертикальный столбец. Разработчик Sabino даже предпринял любопытную попытку создать на этом движке игру в стиле Doom.
Но, разумеется, рейкастер и движок уровня Doom — это далеко не одно и то же. Рейкастер может работать только с сеткой, то есть с квадратными блоками, а значит, все объекты на карте должны иметь одинаковую высоту, а стены находиться под прямыми углами. Doom же устроен сложнее: в нём есть стены, располагающиеся под любыми углами, помещения с разной высотой полов, лестницы, лифты и двери. Ничто подобное невозможно реализовать в простой игре с рейкастингом. Даже в проекте Sabino поворот за угол выглядит не особо естественно. В конечном итоге, мы имеем дело с сеткой из квадратных блоков, поэтому в таком движке с рейкастингом невозможно реализовать что-то наподобие уровня E1M1, The Hangar.
Однако у этой саги «Doom на Neo Geo» недавно появилось несколько продолжений, и я в восторге от того, куда всё это может привести. Как я упоминал в последующем видео, люди действительно серьёзно принялись за решение этой задачи. У нас появились новые подходы к реализации Doom на Neo Geo.
Вышло 2 модели prism-ml/Ternary-Bonsai-27B-gguf и prism-ml/Bonsai-27B-gguf
Модели представлены в 2-битном и 1-битном вариантах и занимают всего 7,2 и 3,8 ГБ соответственно. Но самое интересное здесь не размер, а качество после столь агрессивного сжатия. По заявленным результатам, 2-битная версия сохраняет около 95% качества FP16, а 1-битная - примерно 90%.
Благодаря столь компактному размеру 1-битную модель можно запускать даже на смартфонах. Например, на iPhone 17 Pro Max скорость генерации достигает примерно 11 токенов в секунду.
Для запуска потребовался форк PrismML-Eng/llama.cpp. На RTX 3090 мне удалось получить около 60 токенов в секунду. Скорость вполне достойная, однако потребление видеопамяти меня не устроило: при контексте в 256 тысяч токенов 2-битная версия заняла около 18 ГБ VRAM. В это значение входят примерно 3 ГБ, используемые Windows 11.
Я привык работать с TurboQuant версиями llama.cpp, которые заметно эффективнее расходуют память, при использовании параметров: -ctk tbqp3 -ctv tbq3 объём памяти занимаемый контекстом, сокращается в 4.71 раза. При этом качество такого сжатия контекста, согласно результатам тестов, оказывается примерно на 8% выше, чем у F16.
Давайте сразу оговорюсь, дабы вы не судили меня строго. Я не программист, а скорее маркетолог с навыками программирования и некоторыми знаниями в IT. Но речь в этой статье пойдет далеко не о маркетинге, а о программе, которую мне довелось разработать. Для меня это было внезапно ;-)
Летом 2025 года мне мой муж начал рассказывать о проблемах своей компании. У них просто ужасно много времени уходило на внесение в 1С заявок клиентов. Настолько ужасно, что для этого держали 8!!! офис-менеджеров, при общем штате компании человек в 40. Это чтобы вы осознали масштаб проблемы.
Я хлопала глазами и предлагала воспользоваться стандартным функционалом сопоставления номенклатуры в 1С. Он крутил у виска и говорил, что это не сработает: клиенты любили очень причудливо описывать требуемые позиции.
С чего всё началось
Периодически в дороге и в свободную минутку перебираю новостные ресурсы в поисках свежих новостей. Поймал себя на мысли, что ресурсов у меня безумно много. Я больше трачу времени не на чтение, а на их перебор.
Открываю один ресурс, второй, третий — реклама, баннеры, всплывающие окна. Не успеешь нажать на крестик можно вообще улететь в неизвестном направлении. Вроде ищешь события, а натыкаешь на блогеров, экспертов, мнения и особенно бесят душераздирающие истории представителей богемной тусовки.
Дальше по привычке открываю Телеграм. Там у меня десятки каналов и в каждом события дублируются раз восемь в восьми разных пересказах. А по‑настоящему важного среди всего этого набирается три‑четыре штуки в лучшем случае.
Мне не хватало не ещё одного источника — их и так достаточно. Не хватало того, чтобы кто‑то прошёлся по всему этому за меня: убрал повторы, выкинул лишнее и выдал короткий список по важности. Без экспертов, желтухи, рекламы, баннеров — чистая событийная лента.
Готового продукта с такой логикой для русскоязычного читателя я не нашёл, поэтому стал разбираться, как вообще устроены подобные системы: как они понимают, что две разные статьи — это статьи об одном и том же событии и где заканчивается работа алгоритма и начинаются редакционные решения. Читал документацию, проверял идеи на практике и постепенно собирал систему по кускам. Сначала запряг одну модель, потом две в связке, далее заменил их на третью. Спорил с ними, выбрасывал неудачные варианты, менял правила, так это медленно и превратилось в рабочую систему.
Я много работаю с кодинг‑агентами в Claude Code. В какой‑то момент поймал себя на том, что не представляю, на что уходят токены. Счёт в конце месяца есть, а из чего он складывается, непонятно.
Написал небольшую утилиту: она читает то, что Claude Code и так пишет на диск, и раскладывает расходы по статьям. То, что она показала, мне не понравилось.
