Из-за дефицита бензина заправка превратилась в маленький операционный процесс. Нужен только АИ-95, есть несколько подходящих АЗС, а сам факт «бензин появился» ничего не значит: можно приехать в очередь на десятки машин.

Первую версию портала сделал coding agent. Я дал ему описание проблемы, 5–6 примеров curl к API сервиса и свой шаблон FastAPI-проекта. Агент сам разобрал данные и собрал MVP: поиск АЗС, список наблюдаемых, сбор данных, история. По git — от первого коммита с планом в 09:24 до коммита с MVP в 11:44 (это темп, а не часы человеческой работы).

MVP работал. И отвечал не на тот вопрос. Он показывал, что происходит на моих АЗС, а мне всё равно приходилось смотреть на карточки и решать самому. Я автоматизировал получение данных, но не то, что раздражало.

Дальше оказалось, что одного статуса «АИ-95 есть» мало: общий статус может говорить «есть», а более свежие данные — очередь в 20–50 машин. Появились состояние станции, свежесть данных и четыре вердикта: GO, WAIT, NO_OPTIONS, UNKNOWN. Отсутствие свежих данных — это UNKNOWN, а не «бензина нет». Решение принимает обычный детерминированный алгоритм, LLM в runtime нет: ответ должен быть повторяемым и объяснимым.

Последний шаг — научить систему молчать. Сообщение «бензин появился, но очередь большая» ничего не меняет в моём поведении. Теперь Telegram пишет только тогда, когда можно ехать.

Однажды в 02:01 пришло «Можно ехать за АИ-95». В 03:07 машина уехала, в 03:30 вернулась. До этого я не смотрел ни на карту, ни на сайт.

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

Как мониторинг превратился в decision assistant и почему решение принимает не LLM, разобрал в статье: https://hram.github.io/articles/gdebenz/