От идеи до MVP за месяц: пять примеров разработки с помощью ИИ

Есть шутки о том, что зачастую люди кодят с помощью ИИ «ещё один трекер привычек», и на этом их фантазия иссякает. Часто можно увидеть вопрос: а какие из подобных проектов могут заинтересовать кого-то, кроме своего автора? Где идеи, полезные другим? Что в 2026-м возможно сделать в одиночку или маленькой командой?

А мы в Kodik сейчас провели месячный хакатон, и он показал: людям приходят в голову самые разные идеи. Позже одни могут прижиться, другие угаснуть, третьи видоизмениться — но полезно обратить внимание на само их многообразие. Возможно, это вдохновит ещё кого-то затеять проект оригинальнее, чем тысячная игра «3-в-ряд».

Сейчас итоги хакатона ещё подводятся, и можно проголосовать за понравившийся проект. Победителей объявим 4 августа, и детально разбирать реализации будет смысл уже после этого. А пока что мы расспросили нескольких участников про идеи и процесс. В чём состояла их исходная задумка, и как она менялась в процессе хакатона? Как выглядел процесс кодинга, и с какими сложностями столкнулись? Публикуем их ответы.

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

Ответы получили от Drooling cat из команды проекта

О проекте:

В «Маяке» организация публикует задачу: например, помощь приюту, участие в мероприятии или разовую волонтёрскую активность. А волонтёр может найти подходящую задачу, откликнуться, добавить её в избранное и дальше общаться с организацией.

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

Мы захотели сделать сервис, который работает как «маяк», то есть помогает сориентироваться и волонтёрам, и организациям. Исходная идея была просто «сделать платформу, где организации публикуют задачи, а волонтёры на них откликаются». Но в процессе стало понятно, что одного списка задач недостаточно.

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

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

Для нас проект был интересен тем, что он находится на стыке социальной пользы и инженерной задачи. С одной стороны, это понятная человеческая проблема. Есть люди, которые хотят помогать, и есть организации, которым нужна помощь. С другой — внутри проекта оказалось много настоящей продуктовой логики: роли, доверие, коммуникация, отклики, рекомендации, удобство интерфейса.

О процессе кодинга:

ИИ в нашем случае был скорее помощником и ускорителем, а не заменой разработки. Мы использовали его для генерации вариантов кода, быстрого поиска решений, рефакторинга, написания UI-компонентов, проверки логики и иногда для формулировок текстов внутри интерфейса.

Но процесс не выглядел как «написал промпт и получил готовый проект». Приходилось постоянно уточнять задачу, проверять результат, адаптировать код под уже существующую архитектуру и вручную исправлять места, где ИИ не учитывал контекст проекта.

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

Главным способ контроля качества — не принимать код от ИИ вслепую. Мы проверяли, как изменения работают в реальном пользовательском сценарии: регистрация, вход, создание задачи, отклик, просмотр откликов, чат, уведомления, редактирование профиля.

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

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

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

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

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

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

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

Android-приложение для защиты пожилых людей от телефонных мошенников в режиме реального времени.

Автор: Дамир Гилемов

О проекте:

Родственники могут с согласия пенсионера установить на его телефон приложение Family Shield. Тогда во время звонка оно определяет активный разговор, записывает звук через микрофон, анализирует мошеннические паттерны, при их обнаружении отправляет родственнику экстренное SMS и выводит визуальный alert, а также проигрывает пенсионеру звуковое предупреждение о том, что на проводе мошенник. Заходно сохраняет текстовый транскрипт звонка и факт тревоги.

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

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

О процессе кодинга:

У меня уже был опыт с ИИ и я привык перестраховываться, поэтому прогонял свои идеи, видение, желания через одну модель ИИ, далее с ней спорил, выяснял технические сложности и возможности, формировал стек, потом собирал воедино, относил другой модели на анализ, снова менял что-то, снова спорил. И уже потом по расписанному плану проекта получал от определенной модели ИИ промпты на условную неделю, после чего по одной использовал внутри Kodik, потом результат снова на ревью и ручную проверку либо тесты.

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

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

Браузерное расширение для проверки достоверности текстов.

Отвечал Светослав Моисеев

О проекте:

При клике на расширение текст страницы разбивается на отдельные проверяемые утверждения, каждое из которых с помощью LLM проверяется на достоверность, оценивается надёжность источников и выносится вердикт (подтверждено, опровергнуто, непроверямо, спорно).К задумке пришёл при обсуждении идей с ИИ. Из плюсов можно назвать то, что тут уже есть сформированный рынок, но при этом у конкурентов зачастую неудобные/устаревшие решения.

В ходе реализации возникали некоторые сложности:

— Как оптимально разбивать текст на утверждения?

Сначала на ум приходит легковесная модель, возможно, даже локальная. Она могла бы разбить текст на утверждения, передать дополнительный контекст, чтобы они были наиболее понятны и полны, и передать «старшей» модели для анализа и рисёрча. Но возникает проблема: хотя такое решение сокращает время работы «старшей» модели и экономит токены, оно является неоптимальным, потому что разбиение текста из 10-15 тысяч символов на утверждения — долгий процесс даже для моделей вида flash/mini/lite. Решение: жертвовать стоимостью анализа в угоду его скорости, передавать в «старшую» модель сразу весь текст. С развитием проекта это можно оптимизировать, но на стадии MVP выбрана такая стратегия.

— Как сочетать streaming + structured output + research?

Изначально я задумывал, что модель будет стримить проверенные утверждения одно за другим, и они по SSE будут «улетать» клиенту. Но столкнулся с проблемами: например, если попросить ИИ дать источники полем в JSON, он начинает их выдумывать. Согласно документации, необходимо парсить источники из метаданных ответа и вручную закреплять за утверждениями. Список источников приходит в конце ответа ИИ — следовательно, стриминг с источниками либо невозможен, либо нужно сначала стримить без них, а последним SSE-событием подгружать источники для каждого утверждения и раскладывать их. Этот вариант показался мне некрасивым, поэтому я решил отказаться от стриминга в пользу адекватности источников.

О процессе кодинга:

Проект написан на Java 21 + Spring Boot: сам пишу на этом стеке, поэтому решил использовать именно его. Мне 17 лет, занимаюсь программированием около года, сейчас пытаюсь найти стажировку/работу и хожу по хакатонам.

Поначалу я старался писать чистый код с ИИ, но это у моделей получается плохо, даже GLM-5.2 и Claude Opus 4.8 не смогли написать чистый и расширяемый код. Однако на текущей стадии MVP и не требуется расширяемость, достаточно и того «хардкода», который пишет ИИ. Здесь главное — скорость, с которой ИИ это делает. Поэтому я ощущаю, что на этом этапе зря зацикливался на чистоте, без этого смог бы успеть в рамках хакатона реализовать больше функциональности.

Чтобы проект получился стабильным, и прогоняю тесты с помощью ИИ, и руками тыкаю функционал. А также использую хорошие модели ИИ и обсуждаю с ними, как именно планируется всё реализовать.

Автоматическая генерация файлов README.md для софтверных проектов.

О проекте:

Моё желание – упростить разработку. Поэтому я решил создать утилиту для автоматической генерации README.md. Изначально хотел сделать CLI‑инструмент, а в итоге получился целый веб‑сайт для помощи разработчикам. Сейчас в нём есть:

Всё это помогает разработчикам тратить меньше времени на документацию и больше — на код.

Я задумался о идее ещё два месяца назад. Начал с изучения статей – например, «Официальный гайд по промптам от OpenAI для GPT‑5.1» на Хабре, «Как дообучить LLM» и т.д. Пробовал делать прототип с ботами, создавал package.json, писал требования для ИИ – но выходило плохо. Тогда я временно забил и отложил идею.

Когда наткнулся на хакатон Kodik, понял, что это идеальный шанс реанимировать проект. Решил начать всё заново, создал новый репозиторий «Kodik‑README‑AI‑COP» – и пошло гораздо лучше. Свежий взгляд и дедлайн помогли.

Изначально я хотел, чтобы всё работало только в терминале. Но работа пошла настолько быстро, и мне хотелось добавлять всё больше и больше, что я пришёл к веб‑интерфейсу. Добавил плагины, валидацию, бенчмарки – это уже не просто утилита, а целая платформа для документирования. От некоторых идей, правда, пришлось отказаться – например, от сложной системы ролей, но это уже за рамками хакатона. В планах – доработать веб‑интерфейс, добавить поддержку большего числа языков, выпустить плагины для популярных фреймворков и, конечно, залить всё на Kodik Marketplace.

О процессе кодинга:

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

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

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

Я пробовал разные ИИ – Blackbox, Gemini, Claude, и у всех была одна и та же проблема: они не всегда понимали мой контекст. Приходилось отменять их действия и перезапускать с более чёткими инструкциями. Было и так, что я сам недопонимал, как должна работать архитектура, и мне приходилось ночами сидеть над статьями и видео, чтобы разобраться. Но справился методом проб и ошибок, множества итераций и нескольких бессонных ночей.

Мне 16 лет. Два года назад я вообще ничего не знал про работу ИИ. Полгода разбирался в JavaScript, сверстал свою первую страницу, потом начал наращивать практику, участвовал в олимпиадах/хакатонах (Prod, НТО «Когнитивные технологии», Газпром – там даже занял призовое место). Позже заинтересовался ML и параллельно увлёкся использованием ИИ для написания кода. Я считаю, что кодинг с ИИ станет нормой – как Git, GitHub, Photoshop. Это просто инструменты, которые увеличивают скорость создания интеллектуального продукта. Поэтому я хочу быть в авангарде тех, кто их осваивает.

Платформа для живого чтения книг.

Сергей Верещагин

О проекте:

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

Но потом произошло интересное. По мере развития проекта стало ясно, что чтение может быть не только личным, но и глубоко социальным занятием.

Поначалу были добавлены простые форумы для обсуждения книг. Казалось, достаточно. Но в диалоге с ИИ-агентом о функции совместного чтения вдруг возникла идея живого чтения, которой не было в спецификации.

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

Так появилась идея VoxLibris — от латинских vox (голос) и libris (книги). Платформа социального чтения, где книжные клубы перешли от форумов и чатов к живым сессиям чтения, а авторы-чтецы получили прозрачную систему монетизации вместо неясных схем заработка на YouTube.

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

В итоге сейчас VoxLibris — это:

Всё на TypeScript, React, Express, PostgreSQL, с Docker-деплоем и ручными миграциями для production-контроля (при первоначальном деплое на чистый сервер миграции применяются автоматически).

О процессе кодинга:

Года два-три назад, без программистского бэкграунда, мне даже в голову не приходило создавать что-то сложнее HTML-верстки или настройки готовой CMS вроде WordPress или InstantCMS. Максимум — сайт на ModX по инструкциям из интернета.Когда появился доступ к LLM, стал экспериментировать. Сначала — калькуляторы. Расчёт материалов для аквариума, навеса для авто, расчёт электрического импеданса, частоты кавитации, расчет объёма жидкости в ёмкостях. Мелочи, но каждый раз ИИ справлялся, и это работало.

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

В VoxLibris сам не написал ни строчки кода — его писали LLM. Моя роль – постановка задачи и контроль исполнения.

Сначала потребовалась фаза обучения. Имел базовые представления о безопасности, производительности, UX из опыта с CMS. Но недостаточно, чтобы самому задавать стратегию реализации важных подсистем.

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

Для каждой подсистемы (аутентификация, клубы, живое чтение, платежи, потоковое вещание) было затрачено значительное время на составление требований и ограничений в виде подробного технического задания:

Чем детальнее был промпт, тем качественнее получалась реализация.

В процессе возникали отдельные проблемы:

1. Компания, сотрудником которой я являюсь, выдавала бесплатный доступ к GitHub Copilot c доступом к лучшим моделям – Claude 4.5 Sonnet, Opus, GPT-5.5. Но после того, как GitHub перешла на новую систему оплаты, бесплатный доступ к нему был закрыт, и остались китайские модели. Это больнее, чем кажется: вернуться на локальные или открытые альтернативы – как пересесть с Tesla на Lada. Быстрого решения нет. Пришлось выкручиваться, пробуя решения от разных провайдеров, экономя запросы к платным моделям.

2. Выгорание. Основной объём работы — не кодинг (кодят ИИ), а продумывание архитектуры и фич, анализ вариантов решений. И это, как оказалось, может быть утомительнее, потому что требует постоянной творческой активности. Бывает, основные задачи вроде закончены, но проект не завершён, а ты в ступоре – не хочется открывать редактор, не хочется даже думать, как реализовать следующий модуль. Нет идей, нет мотивации.

Решение нашлось эмпирически: перерыв в 3-5 дней. После отдыха идеи вернулись, работа снова доставляет удовольствие.

В итоге получилась работающая социальная платформа. Но это произошло не потому, что ИИ написал «всё за меня». А потому что бы чёткий взгляд на проблему, модели работали как «расширенный» мозг, помогая продумать архитектуру и выявлять ошибки, и контроль качества был встроен с самого начала.

Напоминаем, что это «предварительный» текст: сейчас идёт голосование (и вы можете в нём поучаствовать!), награждение победителей ещё впереди, и мы пока не называем «лучшие проекты хакатона»,

Но по этим примерам интересно заметить вот что:

И такого подхода было бы здорово видеть побольше — не только на хакатонах, а вообще в мире ИИ-кодинга.