У моей кошки Манишки диабет. Ей 13 лет, весит она всего 3 кг, и каждый день я меряю ей сахар глюкометром и колю инсулин. Первые месяцы записывал показания в блокнот на холодильнике — просто дата, время, цифра. Потом понял что так динамику не увидишь, перешёл на Excel с формулами и цветными ячейками. Потом написал Python‑скрипт который рисовал графики и сохранял их картинками.
Всё это работало, но только для меня. Когда настало время идти к ветеринару с результатами за месяц, я принёс распечатку своего Excel. Пытался объяснить: "смотрите, тут утром было 25, я вколол полторы единицы, к вечеру упало до 8, потом опять взлетело...". Ветеринар кивал, щурился на мои маркеры — но было видно, что полной картины он не видит.
Подумал - а почему бы не сделать нормальное веб-приложение? Зашёл в App Store, погуглил. Приложений для мониторинга диабета у людей десятки, а для животных почти ничего. Те что есть - либо платная подписка по 500₽/месяц, либо заточены под американский рынок.
Написал пост на Пикабу, показал свой самопал. Люди начали отзываться - оказалось, все мучаются с блокнотами и таблицами. Одна девушка написала что у неё огромный Excel с формулами и она боится его потерять.
Решил: буду делать для всех.
День первый: быстрый прототип
Был вечер вторника, 12 ноября. Недавно получил от Anthropic грант на Claude Code на $250, решил попробовать. Открыл терминал и написал что мне нужно: веб-приложение для учёта глюкозы у кошки, с добавлением записей, графиком, статистикой, экспортом в CSV.
Честно ожидал что сейчас начнётся обсуждение требований, выбор технологий, составление плана. Вместо этого через две минуты получил готовую структуру проекта. Ещё через час собрал и запустил локально.
Открываю браузер - работает. Простая страница с формой: вводишь дату, время, уровень глюкозы, дозу инсулина. Жмёшь "Сохранить" - запись появляется в таблице ниже. Есть кнопка "Показать график" - выскакивает статичная картинка с линией. Базово, но работает.
К полуночи я уже вносил реальные данные Манишки за последнюю неделю. Смотрел как рисуется график, как считается средняя глюкоза, сколько процентов попадает в целевую зону. Понял что Excel больше не нужен.
Лёг спать с мыслью "надо бы ещё функций добавить".
День второй: улучшения и AI
Среда прошла в режиме постоянных дополнений. Утром решил добавить AI-анализ - пусть смотрит на данные за неделю и говорит, стабильная ли динамика, нет ли опасных трендов. Описал идею одним абзацем, получил готовую интеграцию с OpenRouter API. Даже промпт для AI был уже написан - с объяснением что такое диабет у кошек, какие нормы, на что обращать внимание.
Днём добавлял мелкие, но важные штуки. Несколько питомцев вместо одного (вдруг у кого-то две кошки). Импорт из CSV чтобы перенести старые записи. Проверку что человек вводит числа, а не всякую ерунду типа "кот123" в поле глюкозы.
График на телефоне был мелкий - попросил адаптировать под мобильные. Страница перезагружалась при каждом добавлении записи - попросил сделать плавно. Каждая правка занимала минут 10-15: описал проблему, получил код, проверил, закоммитил.
К вечеру среды приложение выглядело прилично. Показал жене - она сказала "удобно, давай я буду записывать измерения Манишки через это вместо блокнота".
День третий: осознание проблемы
Четверг, утро. Перечитываю комментарии на Пикабу. Люди интересуются когда можно будет зарегистрироваться, можно ли показывать данные ветеринару прямо с телефона.
Сижу с кофе, смотрю на код. И понимаю что для публичного использования всё не так.
Авторизация сделана на коленке. График - статичная картинка, нельзя зумить или кликать. Самое главное - как дать доступ ветеринару? Создавать ему аккаунт? Врач не будет регистрироваться ради одного пациента. И производительность - если придёт сотня человек одновременно, всё упадёт.
Полчаса думаю. Текущий код придётся серьёзно переделывать. Нужна нормальная архитектура - отдельные сервисы, современный фронт, интерактивные графики.
Описываю Claude все проблемы и что хочу изменить. Отправляю и жду ответа типа "это сложно, давайте постепенно". Получаю: "Согласен, это правильное решение. Начнём с новой структуры. Много логики можем переиспользовать."
Сошлись на такой архитектуре:
Окей. Переделываем.
Дни третий-четвёртый: большая переделка
Четверг после обеда началась переписывание. Вместо одного приложения стало несколько - одно отвечает за пользователей, другое за данные, третье красиво показывает на фронте.
Процесс был не такой гладкий как первые два дня. Чем сложнее код, тем больше мест где что-то идёт не так.
Четверг вечер. Переношу авторизацию - регистрация, вход, токены, обновление токенов. Тестирую: регистрируюсь, логинюсь, выхожу, снова логинюсь. Работает. Параллельно настраиваю базу данных в Docker, мучаюсь с настройками окружения.
Пятница утро. Мигрирую основную логику. Интересно что много кода из старой версии получилось перенести почти без изменений - расчёты статистики, работа с данными, генерация CSV. Переделывать пришлось только обёртки.
Пятница день. Пишем React фронтенд. Тут началось веселье с TypeScript - он периодически ругался на типы данных. Несколько раз проходили по кругу: ошибка компиляции → исправление → новая ошибка → исправление. Раза четыре повторили, пока всё не скомпилировалось.
Пятница вечер. Интерактивные графики на Plotly вместо статичных картинок. Запускаю, открываю страницу и... вау. Можно зумить колёсиком, можно выделить область, можно навести на точку и увидеть точное значение с датой. Совсем другой уровень.
К концу пятницы делаю полный тест: регистрируюсь, добавляю Манишку, вношу записи, смотрю график, запускаю AI анализ, экспортирую в CSV. Всё работает. За два дня почти сотня коммитов и полная переписывание приложения.
День пятый: финальный рывок
Суббота. Приложение отлично работает на ноутбуке, но до публичного запуска далеко.
Первым делом добавляю главную для меня фичу - шеринг с ветеринаром. Владелец создаёт ссылку, ветеринар открывает без регистрации, видит данные питомца. Ссылка истекает через выбранное время. Плюс QR-код для сканирования на приёме.
Описываю задачу, через пару часов получаю готовое решение. Тестирую: создаю ссылку для Манишки, выбираю срок 7 дней, получаю QR-код. Открываю в режиме инкогнито - вижу красивую публичную страницу с графиком, статистикой, таблицей измерений. Внизу надпись про сервис и кнопка регистрации.
Идеально! Представляю как на приёме достаю телефон, показываю QR-код - врач сканирует и сразу всё видит.
Но тут же ловлю себя на мысли: публичная страница доступна любому у кого есть ссылка. Боты могут найти, начать скрапить данные, нагрузить сервер. Прошу Claude добавить защиту - появляется CAPTCHA и лимит в 30 запросов с одного IP. Безопасно.
Следующая проблема - AI анализ. Он думает 5-30 секунд, пользователь не должен столько сидеть на крутящемся спиннере. Первое решение было простым - держать соединение открытым пока AI не ответит. Но это создавало проблему: если запустить несколько копий сервиса для нагрузки, у каждой своё состояние в памяти. Пользователь отправит запрос на один сервер, проверит статус на другом - ничего не найдёт.
Claude предлагает Redis - быструю базу которая хранит состояние и синхронизирует все копии сервиса. Добавляем, настраиваем. Теперь можно спокойно масштабировать.
К обеду настраиваю автотесты - пятнадцать минут на конфиг, ещё пять на секретные токены в GitHub. Теперь каждый коммит автоматически проверяется.
Вечером самое волнительное - реальный деплой. Арендую сервер за 1500 рублей в месяц, поднимаю на нём Docker, настраиваю домен diabnostic.ru, получаю бесплатный SSL от Let's Encrypt. Заливаю код, запускаю.
Пять минут ожидания. Открываю app.diabnostic.ru в браузере.
Работает. Просто работает. С первого раза.
Регистрируюсь как новый пользователь, добавляю Манишку, вношу данные за последний месяц, смотрю как рисуется график. Всё на месте, всё работает. Приложение в интернете, доступно всем.
Итоги
Пять дней работы:
12,500 строк кода
200+ коммитов
~30 часов чистого времени
Потрачено $100 из гранта на Claude Code и 1500 рублей на сервер в Yandex Cloud
Как работал: Читал каждый кусок кода, тестировал, прогонял через SonarQube и Codex. Claude писал, инструменты проверяли, я решал. Типичная фича - 4 итерации по полчаса. Два часа вместо двух дней.
Что AI сделал отлично: Docker конфиги, тесты (покрытие 82%), интеграции с библиотеками, рефакторинг с Flask на микросервисы.
Что требовало меня: Архитектурные решения, бизнес‑логика (нормы сахара, дозировки), безопасность, отладка на проде.
Результат: Приложение работает на diabnostic.ru. Люди могут регистрироваться, вносить данные питомцев. Ветеринары сканируют QR и видят полную картину.
Планы: Уведомления об уколах, мобильное приложение, интеграция с глюкометрами.
Вывод: AI — ускоритель для того кто умеет. Без хотя бы базовых знаний веб‑разработки и DevOps не смог бы. Но с ними — 5 дней вместо месяца. Экономия 70-80% времени на рутине. Креативность и решения остались за мной, AI просто быстрее воплощает идеи в код.
Комментарии (86)
farfromsouls
16.11.2025 11:30AI - ускоритель для того кто умеет.
А уметь надо всё-таки достаточно, по крайней мере интуитивно и логически понимать архитектуру проекта и всего что AI предлагает. В рамках такого проекта - использование AI просто прекрасное. Но если всё-таки уметь чуть меньше, или проект несколько больше, то есть гигантские риски напороться на проблемы определенных решений, за которыми будет следовать бесконечный реинжениринг и рефакторинг. Тут я не докапываюсь, но считаю это важным уточнением.
А сам проект просто замечательный, бесконечный респект автору за такой сервис.
teamfighter Автор
16.11.2025 11:30Спасибо за высокую оценку. Согласен, если проект разрастется будет гораздо сложнее его поддерживать через ИИ. Но тут довольно простая бизнес логика, и сервисов по сути всего два. Зато их можно горизонтально масштабировать =)
Вообще я Lead DevOps, и в разработке разбираюсь довольно поверхностно, но на мой взгляд достаточно чтобы выстроить архитектуру проекта. Нагляделся уже на узкие места в реальных прод окружениях, опыт мне кажется помог)
Moog_Prodigy
16.11.2025 11:30То есть вы вполне могли и написать это все сами. Только времени ушло бы много. А написал ИИ под вашим чутким руководством. Ну и отлично!
Вот он, эталонный пример как пользоваться ИИ, а не вот это вот всё. Обычно пишут промпты "у меня кошки диабет инсулин напиши прогу чтобы поле ввода и график по времени, и чтобы ветеринар видел" - они же обычно и орут, что ИИ бесполезен и не нужен.Вы сделали просто отличную работу и для себя, и для кошки, и ваша статья должна стать примером для других.
teamfighter Автор
16.11.2025 11:30Мог бы наверное. За полгода где-то)
Каждый коммит - отдельный промпт.
Только в мастере этих коммитов уже хорошо за 2 сотни)
Elendiar1
16.11.2025 11:30За полгода? Такое простое приложение? Серьёзно?
От силы за неделю, из которых последние 3-4 дня будет допиливание логики и красивостей.
Я с нуля, вкатываясь в докер, джангу и реакт за 3 месяца написал внутреннее вебприложение с кучей моделей, сложными вложенными формами и прочими графиками.
Advisory
16.11.2025 11:30Вместо того, чтобы себя расхваливать, лучше бы Автора поддержали.
Wesha
16.11.2025 11:30Предлагаете поддержать распространение (компьютерной) безграмотности?
Вот если бы аффтар написал нечто вроде «я за месяц изучил реакт и накропал приложуху» — то поддержал бы.
Advisory
16.11.2025 11:30если бы аффтар написал нечто вроде «я за месяц изучил реакт и накропал приложуху» — то поддержал бы
Некоторых почитаешь, так они KDE под FreeBSD патчили еще до того, как писать начали. Но фреймворк «Поддержать 1.0» в глаза не видели.
print("Hello, Author")— segmentation fault.
teamfighter Автор
16.11.2025 11:30Круто! Значит для вас это простая задача - микросервисы на FastAPI с роутерами, Swagger API, AI интеграция с промпт-инжинирингом, интерактивный Plotly, Redis для синхронизации состояния, PostgreSQL, Docker Compose, автотесты 82%, CI/CD в GitHub Actions.
Но я и не разработчик, я маску на стройке нашел)
Для меня результат за 5 дней вечерами после работы - хороший темп.
Главное что приложение работает в проде и помогает людям. Остальное вторично.Wesha
16.11.2025 11:30Для меня результат за 5 дней вечерами после работы - хороший темп.
А ви таки куда-то спешили?
Seklth
16.11.2025 11:30Да, можно написать всё самому, но ведь мы же упираемся в лимит времени и ресурс внимания. Одно дело заниматься всем этим в 20 лет, когда его куча. Другое дело в 35-40.
У меня похожая история с переделкой приложения под себя https://habr.com/ru/articles/967024/ . И если делать самому то это займёт уйму времени, когда ты сталкиваешься с технологиями, с которым никогда не работал.
И выходит, да, что ИИ это отличный инструмент ускорения разработки.
Gwilwo
16.11.2025 11:30Добавьте ещё возможность офлайн работы с сохранением данных на устройстве. Без этого не надёжно.
teamfighter Автор
16.11.2025 11:30Интересная мысль, записал
ADEXITUM
16.11.2025 11:30В pwa обернуть, работать с данными через кэш и вообще будет красота) Даже в сторы можно выложить, но там просто завести аккаунт уже целое испытание... Кому надо лучше из браузера себе на телефон поставят.
posledam
16.11.2025 11:30Я может проглядел, что использовали для взаимодействия исходного кода и Claude? Какие инструменты? Или копировали исходники из чата и обратно? Спасибо.
teamfighter Автор
16.11.2025 11:30https://claude.ai/code оказался довольно удобным для работы с репо на гитхабе.
Также использовал в vscode плагины Claude Code и Codex.Ещё периодически юзал Aider в связке с OpenRouter, когда заканчивались лимиты, но тут грант от Claude Code оказался весьма в кассу и стало проще)
В целом если подправлять нейронку, то результат выходит более чем приличным. На 12000 строк проекта Code coverage > 80%, maintability по версии Sonarqube рейта "А".
Сейчас вот например за 4 часа прикрутил фичу подтверждения email при регистрации, причем много где я включал ratelimiting.posledam
16.11.2025 11:30Т.е. Claude анализировал код на гитхабе, и вносил коммиты туда? Или комиты локальные? Т.е. вопрос скорее, обязателен ли гитхаб, можно было бы это проделать без него?
teamfighter Автор
16.11.2025 11:30В случае использования вебморды от Claude коммиты действительно вносятся прям на гитхаб, естественно в каждой новой сессии в новую ветку, причем это поведение невозможно изменить. Одна сессия - одна ветка.
В случае использования локальных средств разработки коммиты создаются непосредственно локально же, тут уже можно самому выбирать куда коммитить и в каких количествах)
Типичный МР выглядит вот так примерно:
Осторожно, длинная картинка
posledam
16.11.2025 11:30Понял, спасибо! К сожалению не каждый проект можно разрабатывать с открытым гитхабом, а в наших реалиях, и вообще с любым гитхабом. Отдельная благодарочка за пример с промптом :) Это был следующий вопрос, выгоднее ли разбивать разработку на маленькие итерации, как это делается в обычных командах, или большими постановками. Ещё интересно, может ли ИИ съесть постановки задач, как это делается для людей, например в Confluence-Jira, но это наверное тема для отдельных статей.
teamfighter Автор
16.11.2025 11:30Ну гитхаб-то тут как раз закрытый) Утилиты что codex что claude code прекрасно работают с приватными репозиториями. Другой вопрос что контекст может рано или поздно куда-то утечь. Фичи нейронка "прожевывает" довольно неплохо.
Вот например вернемся к подтверждению email - исходный промпт выглядел так:Сейчас регистрация доступна без подтверждения Email Нам нужно реализовать подтверждение, вероятно, в рамках сервиса auth (но через роутеры/сервисы, вот это вот всё) Использовать будем для этой цели Yandex Cloud Postbox. Юнит тесты обязательно. Обязательны рейтлимиты (желательно конфигурируемые) Письмо с подтверждением регистрации должно быть оформлено в фирменном стиле. В письме должен приходить код подтверждения, который надо ввести на этапе регистрации (шестизначный) Подумай, может я что-то ещё забыл.
И дальше ряд (около 20) мелких уточнений, включающих в себя требования написать юнит тесты, поправить фронт, разобраться с проблемами при регистрации.
В целом вполне себе короткая постановка задачи.
Конечно чем детальнее промпт тем лучше. Но ведь никто не мешает "готовить" промпт через ту же нейронку?)
Вот кстати шаблон, который был нагенерен в рамках промпта выше:
Тыц
posledam
16.11.2025 11:30Кстати да, я немного поработал с Claude и ChatGPT, для написания развесистой утилиты, меня результат удовлетворил. Правда только через чат. Но понял, что сначала надо поработать над самим заданием вместе с ИИ, прежде чем позволить нейронке срочно бросаться код генерить. Так получается меньше корректировок и меньше необходимости повторного ревью кода. С этой стороны открывается огромный простор для системных и бизнес-аналитиков :)
posledam
16.11.2025 11:30Отдельно плюс за требования к рейтлимитам :) Видимо на опыте.
teamfighter Автор
16.11.2025 11:30Ну да, уже хапали проблем на проде с ними когда-то) Теперь это best practice)
ADEXITUM
16.11.2025 11:30Это прям агент. Подключается к репе и делает все сам. Почти вот истратил свой 250 долларовый грант - чуток в шоке от того какое кол-во кода он может переварить, отрефакторить... Сделать типовой лендинг с огромной кучей контента, анимациями и всем таким. В общем круто очень, но реальные таски с реализацией бизнес логики делать очень неудобно...
teamfighter Автор
16.11.2025 11:30Только что допилил фичу по восстановлению пароля по емейлу. Заняло ровно 2 промпта.
Секрет тут прост - промпты надо просить у chatgpt codex, дав возможность ознакомиться с проектом)
Вот пример на мою фичу:Промпт
Ты — senior fullstack разработчик в проекте Diabnostic (микросервисная архитектура: отдельный Auth-сервис на Python/FastAPI, отдельный API-сервис и React/TypeScript SPA-фронтенд). В проекте уже реализованы:
Подтверждение e-mail при регистрации (с 6-значным кодом, TTL 15 минут, отправка через Yandex Cloud Postbox по AWS SES-совместимому API, фоновые задачи через FastAPI BackgroundTasks).
Рейтлимиты для e-mail-верификации (отдельно на отправку, проверку и повторную отправку).
Авторизация через JWT в HTTP-only cookies.
Капча (Cloudflare Turnstile / Яндекс Smart Captcha) на формах регистрации/логина.
Задача: реализовать фичу “Восстановление пароля по e-mail” на бэкенде (Auth-сервис) и фронтенде (SPA), в том же стиле, что и текущая e-mail-верификация. Учти безопасность, UX и рейтлимиты.
1. Общие требования
-
Нужен полноценный flow:
Пользователь на странице логина нажимает “Забыли пароль?”.
Переходит на отдельную страницу, вводит свой e-mail (и капчу, если она включена).
Получает письмо со ссылкой для сброса пароля (одноразовый токен + ограниченный срок действия).
По ссылке попадает на страницу “Сброс пароля”, вводит новый пароль, подтверждает.
Пароль меняется, все активные сессии этого пользователя инвалидируются.
Никаких утечек информации: во всех ответах API нельзя явно говорить, существует ли пользователь с таким e-mail. Ответ всегда “Если такой e-mail зарегистрирован, мы отправили инструкцию по восстановлению пароля”.
-
Используй уже существующую инфраструктуру:
тот же механизм отправки писем, что и для e-mail-верификации;
ту же систему рейтлимитов (slowapi или что сейчас используется);
ту же систему шаблонов HTML/текст-писем (сделай отдельный шаблон “reset password”, но в том же стиле).
2. Backend (Auth-service, FastAPI)
2.1. Модель данных
Добавь сущность для токенов сброса пароля. Вариант: отдельная таблица
password_reset_tokens:id(UUID или serial).user_id(FK на таблицу пользователей).token(достаточно длинный случайный urlsafe string, ≥ 32 байт).created_at(timezone-aware).expires_at(timezone-aware, TTL ~ 30–60 минут).used(BOOLEAN, по умолчанию false).
Требования:
-
Один пользователь может иметь несколько токенов в истории, но одновременно активным должен быть только один:
при создании нового токена все предыдущие неиспользованные токены этого пользователя помечаются как
used=trueили логически инвалидируются.
Желательно индекс по
token.
Напиши alembic-миграцию в том же стиле, что и существующие миграции.
2.2. Эндпоинты
Реализуй следующие эндпоинты в Auth-сервисе (пути можешь скорректировать, но придерживайся духа):
-
POST /auth/password-reset/requestВход: JSON
{ "email": "<string>", "captcha_token": "<string>" (опционально, если включена капча) }.-
Логика:
Нормализовать e-mail (lowercase, trim).
-
Если пользователь с таким e-mail существует и активен:
создать запись в
password_reset_tokensс новымtokenиexpires_at= now + 30 или 60 минут;отправить e-mail со ссылкой вида:
https://<frontend_host>/reset-password?token=<token>
(URL берём из конфигурации, не хардкодим).
Если пользователя нет — просто не делать ничего, кроме фиктивной задержки (чтобы не было времени ответа в качестве сайд-канала).
Ответ всегда 200 OK:
{ "message": "Если такой e-mail зарегистрирован, мы отправили инструкцию по восстановлению пароля." }-
Безопасность:
Рейтлимит по IP и по e-mail (см. ниже).
Валидация капчи, если она включена (использовать текущую реализацию).
-
POST /auth/password-reset/confirmВход: JSON
{ "token": "<string>", "new_password": "<string>" }.-
Логика:
Найти
password_reset_tokens.token == token.-
Проверить:
существует ли токен,
used == false,expires_at > now().
Если что-то не так — вернуть 400 или 422 с общим сообщением вида
"Неверный или просроченный токен", без деталей.-
Если всё ок:
обновить пароль пользователя (используй тот же хешер/валидатор, что и при регистрации/смене пароля),
пометить токен как
used=true,инвалидировать все существующие сессии/refresh-токены этого пользователя (если у нас есть такая механика; в простом варианте можно обновить поле
password_changed_atи завязать проверку токенов на него).
Ответ 200 OK:
{ "message": "Пароль успешно изменён" }
Опционально:
Если удобно, можно добавить вспомогательный эндпоинт
GET /auth/password-reset/validate?token=..., который просто говорит фронту, что токен жив/мертв, чтобы красиво показать страницу.
2.3. Рейтлимиты
На
POST /auth/password-reset/request:Рейтлимит по IP: например, 5 запросов в час.
Рейтлимит по e-mail: например, 3 запроса в час и 10 в сутки.
-
Используй ту же систему, что и для e-mail-верификации (slowapi или аналог). Если уже есть утилиты для рейтлимита, добавь отдельные ключи/константы, аналогично:
RATELIMIT_PASSWORD_RESET_REQUEST_IPRATELIMIT_PASSWORD_RESET_REQUEST_EMAIL
Логика:
При превышении лимита возвращать 429 с локализованным сообщением.
2.4. Безопасность и логирование
Не логировать токен в явном виде в обычный лог (можно частично замаскировать).
-
Логировать события:
запрос сброса пароля (user_id если найден, IP, user-agent),
успешный сброс пароля.
Не раскрывать в API, есть ли аккаунт с таким e-mail.
3. Frontend (React/TypeScript SPA)
3.1. Страницы и маршруты
-
Ссылка “Забыли пароль?” на странице логина
На странице логина добавь ссылку/кнопку “Забыли пароль?”.
При клике — переход на новый маршрут, например
/forgot-password.
-
Страница “Забыли пароль” (
/forgot-password)-
Форма:
поле
email(с валидацией формата и обязательности),виджет капчи, если включена (используй тот же компонент, что и в регистрации/логине),
кнопка “Отправить инструкцию”.
-
Состояния:
начальное,
loading (крутилка на кнопке),
success (показываем сообщение “Если такой e-mail зарегистрирован…”),
ошибки (сетевые, 429, капча, прочие).
-
Поведение:
После успешного POST запросе всегда показывать один и тот же success-экран, не держа пользователя в неведении.
Если пришёл 429 — показать аккуратное сообщение о слишком частых попытках.
-
-
Страница “Сброс пароля” (
/reset-password?token=...)-
При монтировании:
прочитать
tokenиз query-параметров;если токена нет — показать ошибку и ссылку “На страницу логина”.
-
Форма:
новое поле пароля,
подтверждение пароля,
валидация сложности пароля в том же стиле, что на регистрации (длина, допустимые символы).
-
При сабмите:
отправить
POST /auth/password-reset/confirmс{ token, new_password }.-
Показать:
успех — “Пароль успешно изменён, теперь вы можете войти” + кнопка “Войти” (редирект на
/login);ошибку — “Неверный или просроченный токен” + кнопка “Запросить новый” (ссылка на
/forgot-password).
-
3.2. Локализация
-
Добавь все новые тексты в i18n (RU/EN), в стиле уже существующих ключей:
auth.forgotPasswordauth.resetPasswordauth.resetPasswordDescriptionauth.resetPasswordEmailSentauth.resetPasswordSuccessauth.resetPasswordInvalidTokenи т.д.
3.3. UX/детали
После отправки формы “Забыли пароль?” не оставляй пользователя на той же форме — показать отдельный “success state”.
-
На странице сброса:
два поля пароля с проверкой совпадения,
показать ошибки валидации локализованно.
4. E-mail шаблон
Реализуй новый e-mail шаблон для сброса пароля:
HTML + plain text версии, как и для e-mail-верификации.
-
Содержимое (пример, RU/EN):
Заголовок: “Восстановление пароля в Diabnostic”.
Текст: “Вы (или кто-то ещё) запросили сброс пароля. Если это были вы, перейдите по ссылке ниже… Если нет — просто проигнорируйте это письмо.”
Кнопка/ссылка вида
{{ reset_link }}.Информация о сроке действия: “Ссылка действительна 60 минут”.
Вставлять имя пользователя или e-mail, если есть.
5. Тестирование
Напиши базовые тесты:
-
Backend:
запрос сброса пароля с существующим e-mail → создаётся токен, уходит e-mail;
запрос сброса пароля с несуществующим e-mail → токен не создаётся, e-mail не отправляется, но ответ такой же;
повторный запрос до истечения TTL → создаётся новый токен, старый инвалидируется;
успешный
password-reset/confirm→ пароль меняется, токен помечается использованным;повторный
confirmс тем же токеном → ошибка;confirmс просроченным токеном → ошибка.
-
Frontend:
базовые unit/интеграционные тесты компонентов (по возможности): рендер форм, обработка success/error state, редиректы.
6. Оформление результата
-
Внеси изменения последовательно:
backend (Auth-service: модели, миграции, роуты, сервис, tests);
frontend (маршруты, компоненты, i18n);
e-mail шаблоны.
Обнови документацию Swagger/OpenAPI для новых эндпоинтов.
При необходимости обнови
.env.example(например, если добавляются переменные для фронтенд-URL для reset-ссылок).
Сгенерируй весь необходимый код (backend + frontend + миграции + тесты) в том же стиле, в котором уже написаны e-mail-верификация и существующие Auth-эндпоинты. Если есть сомнения по структуре проекта — сначала кратко опиши план изменений по файлам, затем приводи фрагменты кода по частям.
Wesha
16.11.2025 11:30Глядя на этот не
вдетских размеров промпт, никак не могу отделаться от ощущения, что написать авторизацию самому тупо заняло бы меньше символов.teamfighter Автор
16.11.2025 11:30Сударь, так прелесть в том что этот промпт тоже сгенерированный.
А итоговый PR выглядит примерно так:
Приятно, что вы переживаете за судьбу проекта судя по вашей активности в комментариях)
Wesha
16.11.2025 11:30Проект, я так вижу, приватный. А показать? А то мне тоже поржать хочется.
teamfighter Автор
16.11.2025 11:30За поржать, я так понимаю, вам на пикабу лучше =)
teamfighter Автор
16.11.2025 11:30А так-то конечно можно и поржать, чего бы не поржать. Я в реальной практике такие проекты редко наблюдал)
susbox
16.11.2025 11:30Спасибо за статью и за аппу. Вопрос немного вбок: как у Claude грант получить?
teamfighter Автор
16.11.2025 11:30Прямо сейчас зарегистрироваться там, и до 18 ноября дадут 250$
support.claude.com/en/articles/12690958-claude-code-promotion/Но работает этот грант только в вебморде Claude Code (https://claude.ai/code/)
whocoulditbe
16.11.2025 11:30Уберите рекомендации из ИИ-анализа - он вам кошку до смерти залечит, а потом скажет, что и правда, you are absolutely right, рекомендации могли быть другими, с новой кошкой будем аккуратнее.
teamfighter Автор
16.11.2025 11:30Всё верно, поэтому внизу и есть дисклеймер. В целом ещё думаю над корректным промптом.
whocoulditbe
16.11.2025 11:30Дисклеймер не защитит кошку от действий владельца, он защищает только вас от судебного иска. Анализ данных должен проводить дата-аналитик - лечащий врач. Правильный промпт - "удали дисклеймер с сайта".
teamfighter Автор
16.11.2025 11:30Возможно, формировать ответ от ИИ в духе "Что мне рассказать ветеринару при визите?"
"Наблюдались падения сахара по вечерам от... и до..."При этом исключить даже намек на какие-либо рекомендации по лечению. Что думаете?
На самом деле актуальный вопрос вы задали, сам над ним думаю.
whocoulditbe
16.11.2025 11:30Просто выдайте данные врачу, не надо советов, ничего не надо придумывать. Неправильный пересказ графиков может сбить врача с толку. Лучше добавьте возможность залить фото, бывает, что кота тошнит чем-то, а потом ветеринар спрашивает, как оно выглядело.
На приёме должно быть так: вот график, вот цифры, вот кот (усы-лапы-хвост) - доктор, что думаете? Никаких предположений с вашей стороны и тем более со стороны генеративной модели, которая токены предсказывает.
teamfighter Автор
16.11.2025 11:30Ну я думаю какой-то минимальный анализ, даже скорее компиляцию данных можно оставить, но в целом вы правы. Переработаю этот момент. Спасибо за обратную связь!
teamfighter Автор
16.11.2025 11:30Рекомендации убрал. Спасибо вам за подсказку. Теперь AI только собирает данные в общий отчет и прилично отупел. Думаю то что нужно)
Пример
Lord_of_Rings
16.11.2025 11:30Оффтопик
Давно ли диабетом болеете? Сам кошатник со стажем, интересно)
teamfighter Автор
16.11.2025 11:30Пару месяцев всего. Боремся вот как можем.
Lord_of_Rings
16.11.2025 11:30За аппку респект, вам сил и терпения! Всякое с кошками было, по опыту знаю как это все не легко, особенно когда лечить не умеют(
teamfighter Автор
16.11.2025 11:30Буду надеяться что принесет пользу. А лучше чтобы вообще не понадобилась по причине выздоровления =)
Wesha
16.11.2025 11:30Одна девушка написала что у неё огромный Excel с формулами и она боится его потерять.
...но мысль о бэкапах в светлой голове так и не заворочалась.
Wesha
16.11.2025 11:30Бэрримор, какое такое "защищённое DRM аудио или видео" этот пепелац пытается воспроизвести???
teamfighter Автор
16.11.2025 11:30Вероятно капчу) О баге знаю, буду фиксить) Хотя это наверное даже не баг а фича. Сейчас используется яндекс смарткапча, которая иногда просит ввести что-то там текстом. И там есть возможность проигрывания текста на слух. Наверное оно.
Wesha
16.11.2025 11:30проигрывания текста на слух
Бэрримор, не кажется ли Вам, что защищать DRM слова «семь три шесть девять» — это немого перебор?
teamfighter Автор
16.11.2025 11:30Сэр, отвечу ставшей уже классической фразой - все вопросы к яндексу!)
Но вообще странно конечно, посмотрю откуда там уши могут расти. Ставлю всё таки на капчу.
vcKomm
16.11.2025 11:30Думаю, это фингерпринтинг яндекса от капчи. Это разрешение вылезает и на других сайтах с ней
lxnvr
16.11.2025 11:30Для данного кейса (ведение статистики без ненужных AI-советов) можно просто сделать толковую гугл-таблицу и поделиться ей ридонли, пользователь создаёт копию и работает в ней, цена вопроса 0 рублей.
teamfighter Автор
16.11.2025 11:30Я так и делал! =)
Проблемы начались на приёме у ветеринара. Показываю таблицу на телефоне - мелко, неудобно. Распечатка - врач не понимает мою структуру. Расшарить файл можно, но каждый владелец приходит со своей таблицей в своём формате - ветеринару каждый раз надо вникать.
Плюс у врача должны быть все его пациенты с диабетом в одном месте, а не россыпь чужих Google Sheets. И временный доступ через код удобнее чем "дать права → не забыть отозвать".
Так что таблица отлично работает для личного учёта. Но для взаимодействия "владелец → врач → 10-20 пациентов" нужна стандартизация.
И кстати, именно эту фичу с доступами для ветеринаров я сейчас и пилю.
lxnvr
16.11.2025 11:30Так формат единый - создателя, а делимся не листом с сырыми данными, а сводкой или диаграммой. О разном говорим
Dr_Faksov
16.11.2025 11:30У меня возник всего один вопрос - что изначально мешало принести ветеринару не таблицу Excel а график? Или ваш Excel строить графики не умеет?
teamfighter Автор
16.11.2025 11:30Умеет, я так и делал. Строил график, сохранял PNG, показывал с телефона.
Проблемы:
Один статичный график без интерактивности - нельзя зумить в интересный период, кликнуть на точку чтобы увидеть точное значение
Надо было показать несколько метрик - отдельный график глюкозы, отдельный инсулина, скользящую среднюю. Получалось 3-4 картинки
Перед каждым приёмом обновлять графики, сохранять, закидывать на телефон
Да, это работает. Но это костыль. Веб-приложение с интерактивными Plotly графиками просто удобнее - открыл ссылку, всё актуальное, можно покрутить.
Плюс для ветеринара это будет разовая картинка от одного владельца, а система где все пациенты в одном интерфейсе.
alesh1n
16.11.2025 11:30Отличная статья, спасибо.
Вопрос - приложение планируется становится платным? Как вы будете хотя бы расходы на сервер покрывать?
teamfighter Автор
16.11.2025 11:30Базовый функционал (трекинг, графики, экспорт, шеринг) планирую держать бесплатным. Могут появиться премиум-фичи для продвинутых пользователей, но это опционально.
Основная ставка - на B2B. Ветклиникам нужен единый интерфейс для всех пациентов с диабетом, статистика, возможность оставлять рекомендации. Это уже профессиональный инструмент за который готовы платить.
Сейчас расходы - 1500 руб/мес на сервер. При десятках пользователей это копейки. Если вырастет до тысяч - тогда монетизация станет актуальной.alesh1n
16.11.2025 11:30Ветклиникам нужен единый интерфейс для всех пациентов с диабетом, статистика, возможность оставлять рекомендации. Это уже профессиональный инструмент за который готовы платить.
Вы уверены?)
Пишу, как человек, который недавно чуть ли не ушел в разработку нового сервиса, но перед этим решил сделать опрос ЦА и понял, что это мало кому нужно.
teamfighter Автор
16.11.2025 11:30Честно? Не уверен :) Это гипотеза.
Сейчас фокус на владельцах - делаю бесплатный инструмент. MVP кабинета ветеринара с доступом по кодам уже написал, но пока не знаю нужно ли это рынку. Если соберу пару сотен активных пользователей - пойду валидировать B2B у реальных клиник.
А может окажется что им вообще не нужно, и проект останется некоммерческим для комьюнити.
Расскажете про свой опыт? Какую ЦА опрашивали и что выяснили?alesh1n
16.11.2025 11:30Расскажете про свой опыт? Какую ЦА опрашивали и что выяснили?
Собирался делать сервис видеоповторов для тенниса, сходил к хозяевам кортов и понял, что им это не очень интересно (или готовы за копейки). А еще у меня был опыт разработки устройства для кошек (вот статья) и там тоже с экономической частью пролет)
Если соберу пару сотен активных пользователей - пойду валидировать B2B у реальных клиник.
Мне кажется можно не ждать и уже сходить.
У Вас получается ЦА - это хозяева кошек, а зарабатывать хотите с клиник. Боюсь им это будет не очень интересно если не решает их какую-то боль.
teamfighter Автор
16.11.2025 11:30Девайс для кошек очень понравился, классное решение) У моих кошек правда лотки не в туалете стоят, но потенциал у такого решения как мне кажется есть)
В теннисе к сожалению разбираюсь как свинья в апельсинах, так что ничего не могу сказать)Боюсь им это будет не очень интересно если не решает их какую-то боль.
Прежде всего это довольно удобный трекер глюкозы, и прежде всего для меня) С клиниками если не взлетит - я не расстроюсь =)
Но наработки некоторые по клиникам уже есть, смею надеяться они могут заинтересовать тот же Белый Клык =)Чуть скриншотов
Dren0r
16.11.2025 11:30Не все же продукты должны требовать плату за прямой функционал, при набранной аудитории затраты могут покрываться дальнейшей рекламой.
Условно, на примере этого трекера, что мешает после показывать по партнерке баннер с препаратами для питомцев, или другие товары для животных.
konst54
16.11.2025 11:30Классное начало, респект!
Интересный заход с фокусом на владельцев. Я начинал копать похожую тему после смерти кошки. Пришел к тому, что клинике как будто не сильно интересно и подзабил.
Эта архитектура применима не только для инсулина, ещё же очень много биомаркеров, динамика которых важна при тех или иных заболеваниях.
Есть ветеринарный софт, который позволяет строить графики.
Динамику тоже можно обсчитывать и иллюстрировать (снижается за неделю быстрее чем за прошлую или так же, и тд).
Есть ещё индивидуальная норма - что для одного ещё нормальный показатель на грани, для другого уже нет.
Если смотреть в сторону клиник - имхо для них важна автоматизация парсинга результатов лаборатории, чтоб не забивать руками (да и владельцам хорошо).
Если интересно - можем пообщаться подробнее, я бы может вернулся к теме, как-то поучаствовал в свободное время.
sdk_inc
16.11.2025 11:30я не увидел у автора ресерча по существующим решениям. Для людей,например, давно есть https://nightscout.github.io/
teamfighter Автор
16.11.2025 11:30В том и дело, что для людей подобных решений полно, а для животных, извините, кот наплакал.
sdk_inc
16.11.2025 11:30Ну оно ж не принципиально от чьего имени данные вносить? Графики строит, шарить данные тоже можно. Прекрасно в докере поднимается (равно как и в прочих сервисах типа хероку и т.д.) Может правда не такое красивое. Я без критики и претензий, если честно. Чем больше решений на рынке диабета, тем лучше нам - диабетикам. Я как пользователь CGM с более чем 7-ми летним стажем (и стажем диабета 24 года) таким проектам только рад.
Berks
16.11.2025 11:30Может уже кто-то написал, но всё равно повторю - на главном экране в описании пациента нужна графа "стерилизован/кастрирован или нет"
aionin
16.11.2025 11:30Спасибо за увлекательную и вдохновляющую историю. Меня заинтересовала точка разворота в сторону переработки архитектуры. Сначала были таблички, python скрипты, потом web приложение на fastapi, как я понял. Потом проверка юзабельности у супруги - POC получен. Насколько правильным вам сейчас кажется такой подход? Как вы писали, многое удалось «перенести в новую архитектуру», но многое ,видимо, и «ушло». В итоге, python полностью вытеснили?
Fangaro
Программа помогла ветеринару скорректировать лечение Манишки? Манишка теперь бодрее? Вы достигли цели в поддержании здоровья своей четверолапой питомицы?
teamfighter Автор
Однозначно помогла. Сейчас по крайней мере я на приеме могу показать сахарную кривую и ветеринар сказал, что ему стало проще делать корректировки доз инсулина.
Сахар стало проще отслеживать и Манишка действительно чувствует себя получше. И это для меня пожалуй основная ценность разработки.
medstrax
Интересно, а зачем здесь ветеринар. ИИ на основании кривой не сможет скорректировать дозировку?
teamfighter Автор
Ии очень любит ошибаться. Ему нельзя доверять. Когда под влиянием ИИ будет введена неверная доза инсулина будет очень грустно.