Как мы с нейросетью за вечер написали свой веб-сервис вместо Google Таблиц — и забыли про тормоза и блокировки

Представьте: утро понедельника, оператор открывает отчёт — а он не грузится. И вчера не грузился. И позавчера. Вроде бы те же онлайн-таблицы, что работали годами, но сервер где-то за океаном, доступ то ли закручивают, то ли сам сервис уходит из России. Знакомая картина для десятков компаний, которые до сих пор сидят на облачных зарубежных инструментах.

В этой статье — честная история о том, как мы прошли путь от «всё пропало» до работающего веб-сервиса, который занимает 20 мегабайт оперативки, летает быстрее любого онлайн-редактора и не зависит ни от одного зарубежного сервера. В главной роли — нейросеть, которая написала 90% кода. И да, это может повторить кто угодно.

Проблема: когда онлайн-таблицы перестают быть «онлайн»

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

И однажды они просто перестали открываться.

Не из-за пароля. Не из-за прав доступа. А потому что доступ к сервису из России стал нестабильным. С VPN — медленно, без VPN — никак. Зарубежные облачные сервисы методично превращаются в тыкву для российских пользователей, и этот тренд только усиливается. Ждать, пока всё наладится — стратегия так себе. Нужно было что-то своё.

«Поставить готовое» — и почему это не взлетело

Первая мысль очевидна: ставим готовый self-hosted аналог таблиц. Тот же NocoDB, например. Красиво, функционально, open-source. Закинул в Docker — и живи.

Но реальность быстро вернула с небес на землю:

• Сервер — скромный. Четыре ядра, ограниченная оперативка, и на нём уже крутится с десяток сервисов. Каждый новый — борьба за ресурсы.
• NocoDB и аналоги требуют отдельную базу данных. PostgreSQL или MySQL — это ещё один контейнер, ещё один потребитель RAM. Свободной оперативки кот наплакал.
• Избыточность. Нам не нужен конструктор таблиц с правами, API и вебхуками. Нужен один конкретный отчёт с тремя пользователями и пятью заходами в день.

Тащить ради этого монструозный комбайн — как возить пакет молока на карьерном самосвале. Нужно было кастомное, лёгкое решение.

Нейросеть в роли разработчика: как это было

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

Не «сгенерирует идею», не «поможет разобраться». А напишет работающий сервис. С нуля.

Шаг первый: загружаем контекст

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

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

Шаг второй: жёсткие ограничения

Я сразу предупредил: оперативной памяти очень мало, отдельную базу не поднять, всё должно крутиться в Docker. Нейросеть предложила два пути: PHP или Python. Проверили сервер — оказалось, PHP не установлен, зато Python уже был. Решение принято: Python.

Шаг третий: фреймворк и архитектура

Нейросеть предложила Bottle — легковесный микрофреймворк, который распространяется одним файлом и не тянет за собой гору зависимостей. Для базы данных — SQLite: встроенная, не требует отдельного процесса, файл базы лежит прямо в контейнере. Идеальное совпадение с нашими ограничениями.

Дальше — больше. Нейросеть не просто набросала код. Она сама предложила:

• разделение на роли: администратор (видит всё, редактирует) и оператор (только ввод данных);
• форму для ввода — интуитивно понятную, с автоподстановкой дат;
• выгрузку отчётов в Excel — потому что «нужно же бухгалтерии куда-то отправлять»;
• графики по дням — визуализацию, о которой я даже не просил, но которая оказалась жутко полезной.

И всё это заработало с первого раза. Не с пятого, не с десятого. С первого.

Что получилось: цифры и факты

На выходе — полноценный веб-сервис в Docker-контейнере. Вот его ключевые характеристики:

• Потребление оперативной памяти: 20–30 мегабайт. Для сравнения: один только браузер с открытой онлайн-таблицей жрёт в десять раз больше.
• База данных: SQLite, встроенная. Никаких отдельных контейнеров, портов и конфигов.
• Скорость открытия: мгновенная. Раньше те же таблицы в онлайн-сервисе грузились тяжело, с задержками. Теперь интерфейс отзывается на клик быстрее, чем моргает экран.
• Надёжность: абсолютная. Сервис на собственном сервере в России. Никаких блокировок, санкций и внезапных отключений.
• Изоляция: Docker. Легко развернуть, легко обновить, легко перенести.

Почему SQLite — это не «временное решение»

Многие слышат «SQLite» и думают: ну, это для прототипов, а в продакшн надо PostgreSQL. Это миф. SQLite держит сотни одновременных чтений и десятки записей без малейших проблем. Для трёх пользователей и пяти заходов в день — это запас прочности на два порядка выше необходимого.

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

Почему это сработало: три слагаемых успеха

Первое — чёткая постановка задачи. Нейросеть не умеет читать мысли (пока). Но если дать ей конкретный файл с реальными данными, описать логику и ограничения — она выдаёт результат, от которого отвисает челюсть.

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

Третье — готовность проверять и докручивать. Да, пару правок я потом внёс руками. Но это были мелочи — подписи полей, отступы в форме. Весь каркас, вся логика, фронтенд и бэкенд — работа нейросети.

Что это значит для рынка и для вас

Мы стоим на пороге тектонического сдвига. Раньше путь от «нужен сервис» до «сервис работает» занимал недели или месяцы и требовал разработчика. Сегодня — один вечер и нейросеть. Порог входа в создание кастомного корпоративного ПО рухнул до нуля.

Это означает, что лёгкие самописные сервисы под узкие бизнес-задачи станут нормой. Зачем терпеть тормоза универсального комбайна, если можно за вечер собрать ровно то, что нужно именно вам? Зачем зависеть от облачного провайдера с непонятной юрисдикцией, если собственный Docker-контейнер на российском хостинге решает вопрос раз и навсегда?

Импортозамещение перестаёт быть дорогим и болезненным процессом. С правильным инструментарием это быстрее, дешевле и — давайте честно — приятнее, чем сидеть и ждать, пока зарубежный сервис соизволит загрузиться.

Заключение: попробуйте сами

Если у вас есть похожая задача — отчёт, который живёт в зарубежных таблицах и в любой момент может оказаться недоступным — не ждите. Возьмите нейросеть, приложите структуру данных, опишите ограничения сервера и попросите сделать сервис на Python + Bottle + SQLite в Docker. Результат может вас серьёзно удивить.

Тот самый отчёт теперь открывается мгновенно. Операторы довольны. Администратор видит графики. И всё это на 20 мегабайтах оперативки. Если это не магия, то я не знаю, как это назвать.