В этой статье расскажу о том как я воплотил в реальность свою идею разработать легковесный prodaction guardrails. Расскажу что такое Guardrails, далее поделюсь основными компонентами lite-guardrails, его архитектурой, этапами разработки, настройкой observability, а также созданием документации по проекту.

На днях в чате разработчиков мне написали: «Я описал Клоду проект с телефона, он собрал MVP и сам задеплоил на Firebase. В деплой я вообще не лез. Зачем теперь нужны сервисы деплоя?». Вопрос честный, и короткий ответ на него: незачем. Если ИИ развернул ваш проект и он работает, всё отлично, расходимся. Длинный ответ интереснее.

День первый: тут ИИ действительно победил

Признаю без оговорок: настройка сервера перестала быть проблемой. Любой ассистент напишет docker-compose, поднимет nginx, выпустит сертификат и объяснит каждую строчку. Гайды, по которым мы страдали вечерами, превратились в один промпт. Это прогресс.
Проблема в том, что настройка и была самой лёгкой частью. Она просто казалась сложной, потому что делалась один раз. А проект живёт месяцы.

День второй и все последующие

Что происходит с сервером дальше, из личного опыта за годы деплоев:

Сертификат истёк в пятницу вечером. Пользователи видят «соединение не защищено», вы узнаёте об этом в понедельник от клиента.

За одну ночь боты сделали 9999 попыток подобрать пароль к SSH. Сервер без защиты для интернета выглядит как открытая дверь, и в неё правда ломятся, обычно в первые же сутки.

Docker Hub перестал отвечать с российских IP. Деплой, который работал год, умер в момент пересборки образа. Кто не прописал зеркала реестра заранее, чинил это в панике на проде.

Диск кончился: каждая пересборка образа оставляет слои, за пару месяцев они съедают всё, и сервер встаёт с «no space left on device».

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

Меня зовут Александра, и я ML-инженер в RUTUBE TECH. В этой статье расскажу, как мой лингвистический бекграунд помог создать единый стандарт логирования для всей платформы.

Как квантование ломает function-calling у LLM? Собрал бенчмарк QuantCall, протестировав модели на 4 ГБ VRAM. Главный инсайт: устойчивость к квантам зависит не от размера, а от семейства. Меньшая Qwen3-0.6B стабильно генерирует валидный JSON даже на Q4, а более крупная Llama-3.2-1B деградирует уже на Q8, путая типы данных. Также GBNF-грамматики не спасают от ошибок, но заметно замедляют инференс.

Эта идея появилась у меня давно.

Когда мы внедряли BI в крупном банке, я заметил одну вещь: больше всего внедрению радовались руководители. У них появлялись дашборды, графики, показатели, визуальная картина происходящего.

А вот люди, которые каждый день работали с данными, не всегда были в таком же восторге.

BI хорошо показывает, что что-то изменилось: появилась аномалия, просел показатель, выросло значение, изменилась динамика. Но после этого почти всегда возникает следующий вопрос: почему так произошло?

И вот тут уже приходится разбираться не с графиком, а с данными.

Причин может быть много: ошибка, поздняя загрузка, изменение записей задним числом, редкое событие, особенность расчёта. Чтобы это проверить, нужно смотреть строки, сравнивать выгрузки, пересчитывать показатели и иногда просто руками разбирать, что попало в отчёт.

У финансистов, которые занимались такими разборами, доступ к хранилищу был ограничен. Они не были техническими специалистами, и это нормально. Но при этом именно им нужно было проверять банковские показатели, сверять расчёты и понимать, что изменилось между вчерашней и сегодняшней выгрузкой.

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

Так появилась первая версия программы: она формировала отчёты в Excel и хранила на сервере историю выгрузок.

На PyCon US 2026 Руководящий совет Python рассказал о новых возможностях Python 3.15. Среди них — явные ленивые импорты (PEP 810): модули теперь можно загружать не при старте программы, а только в момент первого обращения. Я решил разобраться, как это работает, и измерить производительность в PyCharm.

Привет Хабр! Меня зовут Владимир, и недавно я решил изучить новую (для себя) технологию - LlamaIndex. А тут и задачка подвернулась - надоело копаться в Положении о закупках, поэтому понадобился RAG для ответов по ФЗ-44, ФЗ-223, ну и локальному положению.

В этой статье разберу, как создать простенький RAG, не выходящий из локального контура, на базе LlamaIndex + Qdrant, напишем к нему API и UI на Gradio. Поехали.

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

Мы создаем софт для горно-геологических служб калийных рудников, и после первой статьи про [кригинг на чистом NumPy](https://habr.com/ru/articles/1055612/) самый частый вопрос звучал одинаково: «Хорошо, а какой именно кригинг брать?» Вопрос правильный: под словом «кригинг» живёт целое семейство методов, и выбор между ними влияет на результат сильнее, чем тонкая настройка вариограммы. В плагине Isoliner их пять - простой, ординарный, с полиномиальным трендом, блочный и индикаторный, - и каждый существует не для галочки, а под конкретный класс геологических задач.

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

<cut/>

## Общая механика: что меняется, а что нет

Напомню каркас из первой статьи: оценка в точке - взвешенная сумма соседних скважин, веса - решение системы уравнений с ковариациями из вариограммы:

```python

s = np.linalg.solve(A, r)   # A - ковариации соседей между собой,

w = s[:na]                  # r - ковариации соседей с точкой оценки

est = float(np.dot(w, vra))

```

Все пять видов кригинга решают эту систему. Различаются они тем, что считается неизвестным про среднее поле и что именно оценивается - точка, блок или вероятность. Это и есть ключ к выбору.

## Простой кригинг (SK): среднее известно

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

После рабочих встреч часто остаются записи. В моем случае это записи Яндекс Телемоста.

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

У меня часто бывает такой сценарий: нужно передать программисту контекст по задаче. Можно скинуть запись встречи и написать: «посмотри, пожалуйста». Но человеку придется самому смотреть видео, искать важные места, понимать, где обсуждение, где решение, где задача.

Мне хотелось получить более удобный вариант: вместе с записью отправлять текстовый итог встречи.

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

Первую рабочую версию получилось собрать через Codex примерно за 30 минут.

MCP упростил жизнь разработчикам: теперь у AI-агентов есть единый способ подключаться к инструментам и сервисам.

Но у этой стандартизации есть обратная сторона — каждый MCP-сервер становится новой точкой доверия и потенциальной атакующей поверхностью.

В статье разбираю:

-почему у LLM нет чёткой границы между данными и инструкциями -как tool poisoning, indirect prompt injection и sampling abuse работают на уровне MCP -почему даже “безобидные” документы и описания инструментов могут приводить к выполнению команд -какие реальные атаки уже зафиксированы в экосистеме MCP

как индустрия пытается закрыть это через gateways, sandboxing и OAuth-архитектуры

Также показываю практическую проверку на уязвимом MCP-стенде и результаты детекции вызовов инструментов на своем сканере BarkingDog.

Это подробный разбор одного эксперимента. Я взял god node из реального LangGraph агента и попросил 5 американских и 6 китайских моделей сначала предложить, как её распутать, а потом оценить предложения друг друга. Дальше тремя разными способами пытался понять, кому из них в этом деле верить.

Пять промптов, один злой скилл и парсер Хабра: полевой отчёт не-разработчика о двух часах в Claude Code

Всем привет!

Очень долгое время разработчики Telegram-ботов довольствовались двумя способами форматирования сообщений: HTML и Markdown. Оба этих способа делали одно и то же: добавляли простое форматирование в обычный текст.

Для большинства задач этого было достаточно, но в какой-то момент обычного HTML и Markdown может не хватать.

В недавнем обновлении Telegram Bot API 10.1 эту проблему решили, добавив Rich Messages. Обзор которого я и сделаю в статье.

Мы создаем софт для горно-геологических служб калийных рудников. Наши геологи и маркшейдеры каждый день превращают тысячи скважинных проб в карты: отметки кровли пласта, содержания KCl, мощности, газоопасность. Классический инструмент для этого - кригинг, и в QGIS он формально есть: SAGA, GRASS, Smart-Map, связки со SciPy. На практике же каждый вариант чем-то не устраивал, и год назад я начал писать свой плагин. Сейчас Isoliner - это 24 инструмента в официальном репозитории plugins.qgis.org: кригинг четырёх видов, вариограммный анализ, кросс-валидация с отчётами, изолинии с контурными полигонами, геологические разрезы и собственный 3D-просмотр. Вычислительное ядро - чистый NumPy, ни одной внешней зависимости.

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

Самая вычислительно прожорливая индустрия в истории считает на языке, который медленнее C примерно в 70 раз и занял 26-е место из 27 по энергоэффективности. Разбираемся, как Python стал королём ИИ, во сколько обходится его корона — в микросекундах, гигаватт-часах и удвоенном труде инженеров, — и почему новые территории (on-device, edge, локальный инференс) уже отвоёвывают компилируемые языки, в первую очередь Swift. С цифрами, ссылками на первоисточники и разбором честных контраргументов.

Оптимизация потребления памяти в ML-библиотеке LANCETNIC

Недавно я столкнулся с проблемой: моя библиотека lancetnic при обучении на больших текстовых датасетах просто перегружала оперативную память. На ноутбуке с 16 ГБ RAM модель не могла обучиться даже на 25 тыс. строк. Я начал разбираться и нашёл пару причин критического перерасхода памяти.

Привет! Началось всё с дурацкого вопроса. Я который месяц живу в Claude Code — ставлю задачи, ругаюсь, прошу переделать, снова ругаюсь. И тут до меня дошло: каждая моя реплика лежит на диске. Вообще каждая. Каждое «сделай», каждое «проверь», каждый капс в три часа ночи — всё это тихо копится в JSONL‑файлах в домашней папке. У меня таких логов набралось на 200 тысяч слов за полтора месяца. Это, на минуточку, две «Мастер и Маргариты».

И вот сижу я, смотрю на эту гору данных и думаю — а как я вообще выгляжу со стороны машины? Не «хороший я или плохой», а буквально: какими словами командую, в котором часу наиболее опасен, сколько раз прервал модель на полуслове. Досье же готовое. Осталось его вскрыть.

Так за сутки диалога родился Prompt Warrior — опенсорсный скилл для Claude Code и других харнесов, который превращает локальные логи сессий в геймифицированный психологический портрет: титул, уровень, 74 ачивки с редкостями как в Стиме, шесть шкал характера и биография, которую пишет сама нейросеть.

Вас тоже достаёт спам и реклама? Рекламу я блокирую через свой DNS сервер и локальными CSS фильтрами, а вот для почты пришлось придумать что-то другое.

Схема многоступенчатая. Первыми срабатывают фильтры Яндекса и Mail — что-то они отсеивают сами, ещё до пересылки. То, что прошло через них, падает на мой сервер, где стоит SpamAssassin. Ловит ещё часть. Но после двух уровней всё равно что-то просачивается, спамеры же не сидят без дела. И вот этот остаток доезжает до Gmail и что-то оседает в папке Спам, а что-то попадает во входящие и приходит раздражающее уведомление. Хотелось, чтобы со временем не накапливался мусор в папках, который надо разгребать вручную. Особенно важно заблокировать то, что не является полностью спамом: приглашения на конференции, партнёрские предложения, кредиты — формально не нарушение, поэтому байесовский фильтр такие вещи плохо ловит.

Локальная BERT-модель закрыла обе проблемы. Взял ruBert-base-antispam с HuggingFace — файн-тюн на базе DeepPavlov/rubert-base-cased-conversational. 177 миллионов параметров, 12 слоёв трансформера, 768 hidden size. Физически не принимает больше 512 токенов на вход. В памяти занимает около 550 МБ, ответ приходит за 100-200 миллисекунд. Бинарный классификатор — текст на входе, 0 или 1 на выходе, никаких промптов и reasoning. Идеально!

Надоело каждое утро вручную обходить 5+ площадок — написал агрегатор на Python. Собирает вакансии с HH, Habr Career, GeekJob и Telegram-каналов, убирает дубли, присылает в Telegram. Код открытый.

Приветствуем, Хабр.

Мы стараемся лицензировать в издательстве «O’Reilly» и переводить для вас фундаментальные книги, в том числе, по формирующимся парадигмам и подходам к разработке. Одним из наиболее успешных базовых изданий такого рода была книга «Основы инженерии данных» Джо Риса и Мэта Хоусли, вышедшая в середине 2024 года (допечатка – январь 2026). Желая развить эту тему, мы издали и вторую, возможно, не менее фундаментальную книгу «Data Engineering Design Patterns», которую написал для издательства «O’Reilly» Бартош Конечны. Русское издание вышло в конце июня и называется «Инженерия данных. Паттерны проектирования». Автор считает, что в дисциплине инженерии данных можно выделить такие же многоразовые и универсальные шаблоны проектирования типичных решений, как и в традиционном программировании. То есть, он берётся повторить в этой области фундаментальный труд «Банды четырёх», который в середине 1990-х привёл к появлению всем известной книги «Design Patterns». Ранее мы размещали статью с примерами вычленения паттернов проектирования в области инженерии данных — это был перевод, а оригинал статьи написал сам Бартош Конечны, собираясь обосновать готовящуюся книгу и очертить её тематическое поле. Под катом рассмотрим, какие именно темы вошли в новую книгу.

okama MCP бесплатно подключает ИИ-ассистента (ChatGPT, Claude, Gemini) к финансовому движку и данным проекта okama: реальные расчёты доходности, риска и прогнозов вместо выдуманных чисел и галлюцинаций.

Всем привет, это моя первая статья на Хабре, и я решил посвятить ее своему недавнему мини‑проекту, сутью которого является обучение небольшого перцептрона 2-5-1 с помощью Python без сторонних библиотек (типа NumPy), и его последующий инференс на непрограммируемом инженерном калькуляторе Casio‑Fx-82-Es Plus (2^nd edition).

В качестве задачи для перцептрона я выбрал определение того, находится ли точка в пределах графика следующей лемнискаты Бернулли: (x² + y²)² — 2a²(x² — y²) = 0 (с a = sqrt(0.5), то есть вообще без коэффициента 2a²), с минимально приемлемой вероятностью (70–85%)

Большинство AI‑приложений — это просто «запрос → LLM → ответ». PAD+ AI исследует, что должно происходить между этими шагами. Мы построили открытую когнитивную архитектуру с 22 фазами обработки, 6 типами памяти, эмоциональной моделью и полной трассировкой «мыслей» системы через X‑Ray. Это не чат‑бот, а инженерная платформа для наблюдения за процессом принятия решений ИИ.

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

Со временем дневник перестал быть просто электронным блокнотом. Данных становилось все больше, а вместе с ними появлялись и новые вопросы. Главный из них звучал очень просто:

WASM уже вышел за пределы браузеров и выглядит как перспективная технология для серверной разработки. Однако в вопросе серверного компьюта рано или поздно встает вопрос асинхронной обработки I/O-bound нагрузки. В данной статье попробуем разобраться, что как отвечает экосистема WASM на данный вызов. Статья особенно актуальна в свете того, что совсем недавно официально представлен WASI 0.3

А точно ли в наши дни обязательно уметь писать? Какую пользу это несет? Сократ считал, что запись ухудшает память, знаем мы это, впрочем, лишь потому что его ученик Платон его записал. Оставим этот вопрос ученым, мы практики - если что-то можно автоматизировать, значит нужно!

Как на iOS / Mac / open webui/ openchamber / telegram сервере получить свою быструю бесплтаную транскрипцию с пунктуацией и забыть про клавиатуру?

Каждый бэкенд-разработчик рано или поздно сталкивается с ситуацией, когда база данных MySQL внезапно ложится при резком пиковом наплыве пользователей. Классическая ошибка на старте - создавать новое независимое соединение с СУБД на каждый чих приложения, выполнять один короткий запрос и закрывать коннект. Когда на сайт одновременно залетают сотни людей, сервер моментально упирается в системный лимит max_connections и падает с ошибкой OperationalError: (1040, 'Too many connections'), попутно забивая всю доступную оперативную память.

Готовые RL‑окружения удобны для старта, но в реальных задачах редко хватает чужих правил и бенчмарков. В статье разбираем, как создать собственную среду для обучения с подкреплением: задать действия и наблюдения, продумать функцию награды и не сломать обучение на базовых ошибках.

Данная статья написана "по мотивам" этой публикации и обсуждений в комментариях к ней. Я никак не планирую использовать нейросети в своей деятельности, но мне стало интересно, насколько удобоваримый результат можно получить с помощью бесплатной нейросети.

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

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

По условиям кейса организация Meridian, вымышленный крупный B2B-маркетплейс услуг для среднего бизнеса с клиентской базой более 4 млн компаний и оборотом 180 млрд рублей в год, столкнулась с падением выручки и ростом оттока клиентов, а руководству не хватало скорости принятия решений.

Команда победителей хакатона разработала AI-платформу для бизнес-аналитики, объединяющую возможности BI-систем и мультиагентного ИИ.

Как они подошли к решению кейса, почему начали с бизнес-анализа, а не технологий, какие выводы сделали на этапе исследования данных и как это повлияло на архитектуру всей системы?

Хочу рассказать про недавний кейс из своей практики и своих трудовых будней.
Заказчик пришёл с задачей: «Хочу QR-код на сертификатах, чтобы можно было проверить подлинность». У него в голове это выглядело так: он дает мне гугл таблицу с перечнем фамилий, датой, и номером сертификата, скрипт генерирует QR единый для всех сертификатов и как бы этот вопрос закрывается по его мнению. Но при этом должна закрываться самая главная боль - защита от подделки путем переноса QR на другой сертификат. Фактически получалась фикция. С моими возражениями заказчик согласился и я расскажу как мы пришли к криптографическому решению без бэкенда, и покажу конкретный код.

Проблема
Мне как бэкэнд-разработчику приходится работать с деплоем своих проектов, каждый раз одна и та же рутина: настройка сервера, nginx, ssl, безопасность сервера(fail2ban, user), CD и многое другое. Это отнимает очень много времени.

Что сделал
После десятков задеплоенных проектов я понял, что все эти действия можно автоматизировать, и решил написать скрипт.

Обычный LLM-агент, которого просят писать Python-скрипты под КОМПАС-3D, ошибается системно: придумывает несуществующие методы, путает две ветки COM API, ссылается на отменённые ГОСТы, подставляет невалидные значения в аргументы. Промпты и примеры это не лечат. В статье разбираю другой подход: контекст-слой из нескольких механизмов, где каждый класс ошибок ловится отдельно ещё до того, как код дойдёт до живого CAD. Внутри граф API на 47 тысяч узлов, справочник валидных значений, база действующих и отменённых стандартов, проверка сгенерированного кода настоящим C#-компилятором и разбор ошибок исполнения на живом КОМПАС-3D. С примерами кода и реальным фидбеком, который получает агент. Заодно объясняю, почему для такой задачи отказался от MCP.

Один User сначала кажется удобным: его можно принять в запросе, вернуть из API, сохранить в базу и передать дальше.
Но со временем такой класс смешивает разные границы и перестаёт защищать код.

Разбираю на Python-примерах, чем отличаются DTO, schema, model и entity — и когда отдельные классы действительно нужны.

Безопасный AI-мониторинг Oracle в закрытом контуре с использованием Python, Ollama и V$WAITCLASSMETRIC

Введение

В существующей системе мониторинга Oracle уже использовалось разработанное мной решение, которое с интервалом в 1 минуту собирало метрики производительности из представления V$WAITCLASSMETRIC и отображало их в Grafana. Графики наглядно показывали изменения времени ожиданий в классах User I/O, Commit, Concurrency и других, однако они показывали лишь сам факт изменения нагрузки, не объясняя его причины.

Возникла идея: если метрики уже собираются для построения дашбордов, почему бы одновременно не отправлять их локальной языковой модели? Тогда вместе с графиком можем сразу отображать текстовое объяснение происходящего, список наиболее вероятных причин изменения показателей и рекомендации, с чего начать дальнейшую диагностику.

Так появился небольшой эксперимент — дополнить существующую систему мониторинга Oracle локальным AI-ассистентом.

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

Я заинтересовался ML и AI в 2019 году, и с тех пор количество статей и примеров кода в Интернете выросло многократно, но одно, к сожалению, так и осталось неизменно — стиль кодирования примеров и их математичность.

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

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

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

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

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

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

Именно поэтому архитектура проекта получилась такой.

Делюсь опытом: собрал прод-агента на Claude для небольшой студии дизайна интерьера. Чат отвечает на Haiku 4.5, генератор концепций — на Sonnet 4.6, фото из Pexels вместо DALL-E. Без LangChain, без векторной базы, без RAG-фреймворка. Один файл main.py на 712 строк, два промпта. В статье разбираю развилки: почему именно так, на каких граблях постоял (порог кэша 4096 у Haiku, парсинг JSON-обёртки от Sonnet), где этот подход начнёт ломаться. Не «гайд от эксперта» — скорее дневник развилок.