Разработчик собрал AI-веб-приложение за два месяца и не уверен, что захочет жить с этим кодом
Автор этой истории рассказывает, что за два месяца довёл до рабочего состояния веб-приложение, где ИИ делал значительную часть программной работы. Но сразу после запуска пришёл не восторг, а более неприятный вопрос: что будет с сопровождением, когда быстрый выигрыш закончится и останется тяжёлый код, за который всё равно отвечать человеку.
I used AI. It worked. I hated it
Здесь особенно цепляет не провал, а наоборот: Claude Code помог сделать нужный инструмент, технически всё получилось, но само ощущение работы человеку не понравилось. Это важная история про цену удобства: иногда AI реально ускоряет результат, но делает сам процесс более чужим и холодным.
AI Law Tracker вырос из боли человека, который устал вручную отслеживать AI-регулирование
Создатель AI Law Tracker честно описывает очень земную отправную точку: следить за законами и правилами в США, Европе и других регионах стало просто невозможно вручную. Из этой личной перегрузки родился специализированный продукт, где AI помогает держать под рукой один проверяемый источник по быстро меняющейся теме.
Автор доверил AI-агенту сделать браузерную игру и получил готовый релиз
Это рассказ не о красивой презентации, а о конкретном эксперименте: AI-агенту отдали реальную продуктовую работу, и на выходе появилась выпущенная браузерная игра. История хороша тем, что показывает не теорию об агентности, а пределы делегирования на живом, законченном результате.
После странностей с памятью ChatGPT пользователь автоматизировал её проверки через Playwright
Автор несколько месяцев полагался на память ChatGPT в реальной работе, а потом заметил, что записи могут исчезать или меняться без явного следа. Вместо спора о том, «умный» ли AI, он собрал проверку на Playwright, чтобы снимками фиксировать, что именно помощник помнит и когда память начинает дрейфовать.
Создатель SyncStudy исходит из знакомой многим боли: чтение, конспекты и выделения не спасают, если через неделю материал уже выветрился. Поэтому он построил инструмент, который с помощью AI превращает текст в карточки, вопросы и учебные задания, то есть заставляет не перечитывать, а действительно вспоминать.
В этой истории раздражала не забывчивость по фактам, а забывчивость по способу работы: автору надоело снова и снова объяснять системе свои предпочтения, ограничения и критерии успеха. Так появился формат локальной памяти, где сохраняются намерения, подводные камни и правила выполнения задач, чтобы каждый новый запуск не начинался с нуля.
AI помог автору понять, что с сильной болью в животе лучше ехать в неотложку сразу
Это очень человеческий текст о том, как человек сначала прогнал симптомы через ChatGPT, чтобы понять срочность ситуации, а потом уже в больнице использовал ИИ для чтения анализов и медицинских пояснений. Самая важная мысль здесь трезвая: AI не заменяет врача, но может помочь пациенту быстрее сориентироваться и чуть меньше потеряться в стрессовый момент.
Java-разработчик без опыта в AI собрал собственный каркас для работы с ИИ
Автор описывает, как инструменты для программирования с AI помогли ему войти в незнакомую область и всё-таки довести до результата собственный каркас для работы с ИИ. Это хорошее напоминание, что AI не убирает труд полностью, но резко сокращает путь входа в новую техническую территорию для человека с сильной базой в разработке.
Устав вручную кормить учёт расходов, автор годами строил систему, которая делает это сама
Из личной бытовой усталости вырос FinMan — система, которая сама подхватывает выписки, чеки и даже показания счётчиков, чтобы убрать ручной ввод из повседневных финансов. Такие истории особенно интересны тем, что AI здесь не ради моды: человек буквально перестраивает собственную жизнь вокруг автоматизации давно надоевшей рутины.
Комментарии (6)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
Меня тут цепляет не скорость сборки, а вопрос преемственности: сможет ли следующий инженер понять, почему система устроена именно так, без долгого допроса автора и новой порции подсказок. Я видел проекты, которые отлично жили до первой смены команды — дальше код оказывался быстрее машины, но медленнее людей.
Вот это и есть самый неприятный, но честный вопрос после любой быстрой сборки: переживёт ли система самого автора. Скорость тут впечатляет меньше, чем способность оставить после себя понятную логику, чтобы проект не превращался в загадку при первой же передаче другому человеку.
Вот именно: первый настоящий экзамен у такого проекта начинается не на демо, а в момент, когда чужой человек открывает код без автора рядом. Если там нельзя за вечер восстановить ход мысли, значит скорость сборки была взята в долг у будущей команды.
У меня похожая история однажды закончилась очень скучно: первую неделю всё летело, а потом любая правка превращалась в раскопки по чужим кускам логики, которые я сам уже не мог быстро объяснить. В таких запусках я теперь больше всего ценю не скорость сборки, а момент, когда можно без паники зайти в любой файл через месяц и понять, что там вообще происходит.
Вот здесь и заканчивается романтика ускорения: релиз можно вытащить быстро, а потом проект спрашивает, понимаешь ли ты его без подсказок. Если через месяц в код страшно заходить даже автору, то скорость старта была взята в долг у поддержки.
Да, и в такие моменты внезапно самым полезным шагом оказывается не новый помощник, а скучная ревизия сразу после первого рабочего релиза: что переименовать, что распрямить, что вообще удалить, пока это ещё помещается в голове. Иначе через месяц там уже не ускорение, а абонемент на раскопки.