Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Я так и думал.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Нет, что Codex, что Claude прекрасно понимают русский язык.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Спасибо за высокую оценку!
Нет, описанных проблем не было, но я использую VPN, а не прокси.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

А где можно ознакомиться с вашими, несомненно великолепными работами?

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Сударь, вы мне явно пытаетесь что-то сказать. Потрудитесь выражаться яснее. У вас есть какие-то технические предложения или вы просто занимаетесь троллингом?

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

PWA уже готово. Посмотрите мою следующую статью.

Могу я узнать причины Вашей откровенной токсичности в моем посте? Это уже становится похоже на откровенный сталкинг.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Выше дискуссия на эту тему. Всё ещё думаю нужно ли тут вообще AI, а то он действительно может насоветовать так что приложение животному больше не понадобится.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Если честно, сначала я просто делал фичи, которые самому казались интересными. Таблички, скрипты, мини-вебка — всё это были быстрые эксперименты, чтобы понять, что вообще работает.

Приложение изначально было на flask, теперь на fastapi.

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

Python остался в основе, просто теперь это не куча скриптов, а аккуратный сервис.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Спасибо за обратную связь, добавлю эту информацию

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Рекомендации убрал. Спасибо вам за подсказку. Теперь AI только собирает данные в общий отчет и прилично отупел. Думаю то что нужно)

Пример

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

В том и дело, что для людей подобных решений полно, а для животных, извините, кот наплакал.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Спасибо за обратную связь!

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Пишите в тг, с радостью пообщаюсь)

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Фича уже в разработке)

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Интересно, не видел)

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

А так-то конечно можно и поржать, чего бы не поржать. Я в реальной практике такие проекты редко наблюдал)

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

За поржать, я так понимаю, вам на пикабу лучше =)

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Сударь, так прелесть в том что этот промпт тоже сгенерированный.
А итоговый PR выглядит примерно так:

Приятно, что вы переживаете за судьбу проекта судя по вашей активности в комментариях)

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Только что допилил фичу по восстановлению пароля по емейлу. Заняло ровно 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. Общие требования

1. Нужен полноценный flow:

   • Пользователь на странице логина нажимает “Забыли пароль?”.

   • Переходит на отдельную страницу, вводит свой e-mail (и капчу, если она включена).

   • Получает письмо со ссылкой для сброса пароля (одноразовый токен + ограниченный срок действия).

   • По ссылке попадает на страницу “Сброс пароля”, вводит новый пароль, подтверждает.

   • Пароль меняется, все активные сессии этого пользователя инвалидируются.

2. Никаких утечек информации: во всех ответах API нельзя явно говорить, существует ли пользователь с таким e-mail. Ответ всегда “Если такой e-mail зарегистрирован, мы отправили инструкцию по восстановлению пароля”.

3. Используй уже существующую инфраструктуру:

   • тот же механизм отправки писем, что и для 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-сервисе (пути можешь скорректировать, но придерживайся духа):

1. 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 (см. ниже).

     • Валидация капчи, если она включена (использовать текущую реализацию).

2. 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_IP

  • RATELIMIT_PASSWORD_RESET_REQUEST_EMAIL

Логика:

• При превышении лимита возвращать 429 с локализованным сообщением.

2.4. Безопасность и логирование

• Не логировать токен в явном виде в обычный лог (можно частично замаскировать).

• Логировать события:

  • запрос сброса пароля (user_id если найден, IP, user-agent),

  • успешный сброс пароля.

• Не раскрывать в API, есть ли аккаунт с таким e-mail.

3. Frontend (React/TypeScript SPA)

3.1. Страницы и маршруты

1. Ссылка “Забыли пароль?” на странице логина

   • На странице логина добавь ссылку/кнопку “Забыли пароль?”.

   • При клике — переход на новый маршрут, например /forgot-password.

2. Страница “Забыли пароль” (/forgot-password)

   • Форма:

     • поле email (с валидацией формата и обязательности),

     • виджет капчи, если включена (используй тот же компонент, что и в регистрации/логине),

     • кнопка “Отправить инструкцию”.

   • Состояния:

     • начальное,

     • loading (крутилка на кнопке),

     • success (показываем сообщение “Если такой e-mail зарегистрирован…”),

     • ошибки (сетевые, 429, капча, прочие).

   • Поведение:

     • После успешного POST запросе всегда показывать один и тот же success-экран, не держа пользователя в неведении.

     • Если пришёл 429 — показать аккуратное сообщение о слишком частых попытках.

3. Страница “Сброс пароля” (/reset-password?token=...)

   • При монтировании:

     • прочитать token из query-параметров;

     • если токена нет — показать ошибку и ссылку “На страницу логина”.

   • Форма:

     • новое поле пароля,

     • подтверждение пароля,

     • валидация сложности пароля в том же стиле, что на регистрации (длина, допустимые символы).

   • При сабмите:

     • отправить POST /auth/password-reset/confirm с { token, new_password }.

     • Показать:

       • успех — “Пароль успешно изменён, теперь вы можете войти” + кнопка “Войти” (редирект на /login);

       • ошибку — “Неверный или просроченный токен” + кнопка “Запросить новый” (ссылка на /forgot-password).

3.2. Локализация

• Добавь все новые тексты в i18n (RU/EN), в стиле уже существующих ключей:

  • auth.forgotPassword

  • auth.resetPassword

  • auth.resetPasswordDescription

  • auth.resetPasswordEmailSent

  • auth.resetPasswordSuccess

  • auth.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-эндпоинты. Если есть сомнения по структуре проекта — сначала кратко опиши план изменений по файлам, затем приводи фрагменты кода по частям.

Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)

Ии очень любит ошибаться. Ему нельзя доверять. Когда под влиянием ИИ будет введена неверная доза инсулина будет очень грустно.