Normal view

176 ботов, ИИ на чужом ключе и 334 статьи: как я за четыре месяца превратил todo-лист в продукт и разобрал его по швам

За две недели ко мне зарегистрировалось 176 ботов. Я полез разбираться, как они прошли мимо трёх уровней защиты, — и вылез с двенадцатью дырами, к ботам отношения не имевшими: хранимый XSS через JSON-LD, чужие задачи по одному идентификатору, сессия, которую нельзя погасить сменой пароля.

И одна, из-за которой до сих пор стыдно: все мои лимиты по IP обходились одной строкой в HTTP-заголовке. Проверил на собственном проде — сорок запросов, ноль отказов.

Внутри: разбор атаки и аудит с кодом, ИИ-помощник на ключе пользователя (и асинхронный генератор, молча съедавший ответы), 334 статьи как инженерная задача.

Читать разбор

Мы списали uv со счетов. А потом он ускорил наш CI на 80%


Мы списали uv со счетов. А потом он ускорил наш CI на 80%

В Python-сообществе вокруг uv уже несколько месяцев шум: быстрый резолвинг, один инструмент вместо зоопарка утилит и обещание ускорить привычный workflow. Звучит хорошо — пока не проверишь на своём стеке.

Мы так и сделали. Взяли один микросервис: Python 3.14, 37 прямых зависимостей, 153 пакета в lock-файле, приватные пакеты и внутренний Nexus. Ожидание было простым: если uv действительно быстрее Poetry, миграция окупится сама.

Локально получилось наоборот. Резолвинг — да, быстрее. Установка по готовому lock-файлу — нет, иногда даже медленнее. Эксперимент закрыли и остались на Poetry.

Через несколько недель пришлось вернуться. Не из любопытства, а из-за алерта Trivy и сюрпризов Poetry 2 с корпоративными индексами. И вот тогда uv показал себя совсем в другом месте — в CI.

В статье разберем:

- почему локальный бенчмарк uv vs Poetry нас обманул;
- как Poetry 2 сломал привычную разработку без VPN;
- зачем мы писали парсер poetry.lock requirements.txt и почему это оказалось костылём;
- как точечная замена Poetry на uv sync в пайплайне сократила время с 5:10 до 2:50;
- почему в итоге uv стал единым стандартом и локально, и в CI.

Коротко: если инструмент не выиграл с первого прогона — это ещё не значит, что он бесполезен. Часто вы просто мерили не то узкое место.

Читать далее

Одна строка в системном промпте отключала кеш целиком. 1% против 98% на живых вызовах

Токен, прочитанный из кеша, стоит не «немного дешевле». Он дешевле в 10–31 раз: DeepSeek — $0.44 против $0.014 за миллион, OpenAI — $4.00 против $0.40.

Кеш провайдера — префиксное дерево по токенам. Он работает ровно до первого расхождения с прошлым запросом. Дальше — всё по полной цене.

Поэтому одна строка вида Current time: {datetime.now()} в начале системного промпта отключает кеш целиком: время меняется на четвёртом слове, и остальные две тысячи токенов политик и базы знаний каждый раз оплачиваются заново. Хотя не менялись ни разу.

Я замерил это на живых вызовах DeepSeek. Один и тот же агент, одни и те же четыре вопроса, одна и та же минута — разница только в том, куда положить время. Ноль попаданий в кеш против 1152 токенов из 1180.

Потом направил профайлер на 97 877 собственных вызовов Claude Code — 32,5 млрд входных токенов, 98% из кеша.

Внутри: как найти такой баг у себя, почему совпадение текста на 96% ещё не значит, что кеш работает, и какие поломки не видно глазами вообще — схемы инструментов из словаря с плавающим порядком ключей, база знаний из set(), «префикс совпал, а кеша нет».

Плюс отрицательный контроль: сценарий, где фикс не даёт ничего, и инструмент честно об этом пишет.

Инструмент открыт: github.com/Isk4R1oT/prefixcash

Проверить свой промпт

Тренд на «честность»: обзор употребления слова «честный» на Хабре

На прошлой неделе обратил внимание на обильное и, на мой взгляд, не всегда уместное использование слова «честный» на Хабре. Решил детальней изучить ситуацию, собрал данные и в результате оказалось, что мне не показалось и так было не всегда, а пик, возможно, еще не пройден. В этой статье делюсь полученными результатами, методологией и датасетом для тех, кому может быть интересно попробовать найти какие-нибудь закономерности самостоятельно.

Читать далее
❌