Как телеграм бот для парсинга постов превратился в ИС для новостной редакции, пережил Google Sheets, SQLite и рождение собственного сайта. История о том, как костыли становились архитектурой.
Дисклеймер. Данная статья не претендует на туториал, руководство к действию или повторение. В ней я пытаюсь ответить на давно дискутируемый вопрос: может ли вайбкодинг использоваться для нужд реального бизнеса? И кажется, ответ положительный — по крайней мере, в рамках осени 2026 года. Статья написана с согласия моего уже бывшего коллеги @smolyakov. В ней намеренно не указаны названия или торговые марки компании.
Резюме: авторы, не обладающие значительным ИТ-бэкграундом, за короткое время навайбкодили несколько реально работающих сервисов для компании, в которой трудились.
На днях, а именно, 31 августа, вышла новая модель работы с временными рядами от Google — TimesFM-3 (Time Series Foundational Model).
Если вкратце, задача моделей семейства TimesFM — прогнозировать дальнейшее поведение системы на основе ретроспективных данных. Интересно, что для этого исследователи Google применяют токенизацию групп временных отсчетов, а сам трансформер TimesFM — decoder‑only. Также в третьей версии TimesFM заявлена поддержка одновременно множественных переменных (multi‑variate).
Так я был в отпуске и мне было скучно, я вспомнил про старую задачу полуторагодовалой давности: классификация сценариев поведения пользователя на основе данных энергопотребления.
Всем привет! Для меня электричество — это магия, и ИИ — тоже. После того, как я приделал к стене водостойкую розетку, решил что и ИИ можно покорить.
Первым упражнением в вайбкодинге локальной RAG системы стало приложение, которое позволит управлять коллекцией векторных документов и кормить локального агента нужными и вкусными данными.
Сразу к делу — вот репозиторий на ГитХабе, в нем исходники по лицензии MPL 2.0. Приложение для macos 14+, написано на SWIFT и для своей работы тянет только системные зависимости и (при необходимости) пакет установки ChromaDB.
Итак, ты решил стать богатым и знаменитым. Для этого ты начал пилить стартап — отличная идея, до такого еще никто не додумывался.
План простой — ты завайбкодишь классную штуку, выведешь её на рынок, рынок скажет спасибо. Ты всё знаешь и всё умеешь — пятнадцать лет в разработке или пятнадцать роликов на ютубе, тут уж у кого как сложилось. Успех гарантирован, остались детали.
Детали ты, кстати, уже начал. Домен купил, логотип сделал. Потом переделал. Название произнес вслух и послушал, как оно прозвучит в подкасте, когда позовут. Заранее прикинул, что ответишь на «а в какой момент вы поняли, что это выстрелит», будешь говорить скромно, но с достоинством.
Потом три месяца писал код. Это была лучшая часть.
А потом запустился.
Иии... ничего не произошло.
На повестке дня — сервис Яндекс.Музыки. Я меломан, у меня куча лайкнутых треков, и знаете что? Я устала. Устала их лайкать. На телефоне-то всё удобно: сверху висит плашка с названием трека и сердечком, и всё делается за секунду.
А вот десктопное приложение — это просто до свидания. Я амбассадор мака (это слово нынче тренд), и меня дико бесит, что для лайка трека мне приходится сворачивать вкладку или уводить фокус со страницы, на которой я работаю.
Но мы упрямые. (и немного наивные)
Идеальная постановка задачи: нажатием кнопки на наушниках ставить лайк на играющий трек Яндекс.Музыки, если он ещё не лайкнут, и показывать overlay с его названием. А если уже лайкнут — просто написать, что вы его уже лайкнули.
Реалии, к которым я пришла: слёзы, куча матов, экзистенциальный кризис от невозможности переопределить кнопку M на Marshall и, конечно же, гора костылей.
Если интересно — читайте дальше.
Перед совместной поездкой всегда кажется, что главные вопросы — это билеты, жильё и маршрут. Но если вы едете компанией, есть ещё один вопрос, который почти всегда всплывает уже по ходу дела и особенно по окончании поездки: кто кому и сколько должен?
Более года назад мы готовились к поездке в Японию 🇯🇵. Нас было 6 человек и встал логичный вопрос: в чем будем вести учет общих расходов? Казалось бы, в 2024–2025 годах это давно решенная проблема, но на практике всё оказалось максимально неудобно, а делить на всех было бы не очень честно — кто‑то платил за отель, кто то за такси, другой постоянно закрывал счет в барах, хотя брал там только салат и так далее
Поездка в Японию и давняя идея сделать продукт для деления расходов сподвигли нас запустить Popolama — сервис про людей и деньги.
Начнём с того, что по-настоящему «вайблю» я где-то с ноября 25 года. До этого моё общение с LLM строилось на копипасте в ChatGPT, DeepSeek, Gemini и обратно. Рука наловчилась, и я в целом не замечала, сколько времени это всё-таки сжирает. Казалось бы, лишнее действие.
Не сказать что я злоупотребляла общением, но когда ты начинаешь кодить, ты очень уверен в себе и думаешь, что всё делаешь правильно. А как только погружаешься в процесс, начинается это… синдром самозванца, выгорание и тревога. Не сочтите меня пессимистом, но всё так и было))
Пока я училась в университете, слава богу, ChatGPT был отсталой жабой, которая через раз выдавала код с ошибкой. Поэтому я морщила нос и старалась всё делать сама — и аминь, спасибо вселенной, что всё так и было. Иначе, мне кажется, сейчас я была бы не разработчиком, а унылым вайбером, который при слове «конструктор» или «указатели» просто представляет лего и какой-нибудь г. Санкт-Петербург.
А потом случилась революция. И моя компания решила не тормозить.
Здравствуйте. Надеюсь, тут есть люди, которые интересуются вайбкодингом (хотя в списке тем рассылки такой не нашёл, что для меня странно), и уж точно есть те, кто занимается разработкой мобильных приложений. Да, сегодня эти слова очень часто встречаются рядом, что неудивительно. Я большую часть жизни проектировал фронтенд для b2b веб-приложений, но руки всегда чесались в сторону мобильной разработки, случай никак не подворачивался. А тут, как из рога изобилия, посыпались различные ИИ, которые способны после пары абзацев произвольного текста буквально за 5 минут сделать готовое мобильное приложение. Да, я не устоял и попробовал. И доложу я вам, это так. Приложение работает! Но, как говорится, есть нюанс: оно не сильно похоже на то, что вы себе представляли. А уж мне, как дизайнеру, было вообще грустно. Эту грусть я пока не победил, но победил кое-что другое, и это не про дизайн.
Когда эксперт впервые увидел, как моя машина ведёт себя в динамике, он сказал, что без курсов по двигателям и трансмиссиям меня к такому тренажёру подпускать нельзя. Он был прав. Меня позвали перенести с Unity на Unigine тренажёр гусеничной машины. К середине проекта я решил, что новую физику проще написать с нуля, и не написал в ней ни строки руками — весь код делал Claude Code. И да, там будет Патрик Суэйзи.
Ну что, Великий Вайбкодер, сколько тысяч строк кода ты сегодня уже успел сгенерировать? Небось сдал 5 проектов за вчерашний вечер на трёх параллельных работах?
А думал ли ты, кем станешь ты и такие как ты через 10 лет?
Может, всё-таки «Идиократия» ближе, чем кажется? Давайте погадаем немного на лавандовом рафе и прикинем, что же всё-таки произойдёт уже в ближайшем будущем.
Всем привет. Я CRM-маркетолог, который не умел (и всё ещё не умеет) программировать, но всё равно собрал коммерческий продукт: сервис, который создаёт индивидуальные иллюстрированные сказки для детей.
Внутри — n8n, BotHelp, чатгпт (имя нарицательное, к OpenAI не имеющее отношение), генерация изображений, вебхуки, long polling, callback, Google Sheets, костыли, боль, первые продажи, возвраты, ночные правки и примерно 5000 сгенерированных сказок за спиной.
Эта статья — не туториал «как за вечер собрать стартап на нейросетях». Скорее история о том, как при помощи чатгпт можно создать продукт, который работает и при этом не стать программистом.
Спойлер: статья про взаимоотношения с ИИ, но при её написании ИИ не использовался. Читать на свой страх и риск — в конце концов, вы сами виноваты, что платите за интернет.
Начало
Летом 2025 года мне написал бывший работодатель — селлер со стажем, который продавал на маркетплейсах хайповые карточные игры собственной разработки.
Логика продукта была простой: человек покупает физическую игру, сканирует QR-код, переходит в Telegram-бота и получает дополнительный цифровой контент для партии.
Запрос тоже казался простым: нужно было сделать музыкальное лото.
Мой бэкграунд CRM-маркетолога на тот момент позволял собирать простые боты в духе «привет, оплати, получи доступ к вебинару». Поэтому я подумал: легкотня. Взял задаток и начал ваять бота в BotHelp (не реклама: альтернативой рассматривался более функциональный Selbot, но его функционал показался мне слишком сложным, а интерфейс — не самым дружелюбным).
В данной статье я покажу Вам, как вместо загрузки тяжелых ADK и SDK от Microsoft, скачивать легкие .exe утилиты при помощи Microsoft Symbol Server
У меня MacBook Air M4, ПК под Ubuntu 24.04, консальные Claude Code и Codex (каждый хорош немного под свои задачи, как по мне). Я люблю Ubuntu, но вот в поездках Mac прям незаменим — с ним удобно работать, батарея живет достаточно долго, даже в самолете можно комфортно что-то тыкать тачпадом. При этом яблочную экосистему я не люблю, Ubuntu мне ближе и приятнее в использовании. Важный момент: я не программист, так что большая часть моих проектов — это всякая маркетинговая, менеджерская и редакторская штукенция. Поэтому у меня нет под это всё каких-то IDE и т.п. Конечно, разработчики и другие инженеры обычно работают с кодом, а потому просто коммият всё напрямую в гитхаб.
Но к делу. У меня постоянно запущено по 6-10 окон Claude и Codex в терминале и я заколебался проекты синхронизировать через Избранное телеграма — зипами. Плюс хочется, чтобы проекты нормально работали и в той, и в другой нейронке. То есть мне понадобилась какая-то система синхнонизации проектов между разными устройствами и разными нейронками.
Сегодня наконец собрался с силами и доделал такую — выложил ее под Apache 2.0 на гитхабе, можно пользоваться, форкать, дорабатывать и выражать своё «фи» в ишшьюсах и комментариях. Наверянка уже кто-то что-то такое себе делал и я просто изобретаю велосипед. Но что ж теперь поделать, я его уже переизобрел.
В статье расскажу, как делал, что делал, где и что пришлось дотюнивать. Скажу честно, мне эту часть с инструкцией писать было лень и она написана уже GPT, так что простите. Немного пробегусь по стилистике, конечно, но в целом текст править почти не буду.
Семь месяцев назад я опубликовал на Хабре статью про ментальные ограничения в управлении продуктом. Перечитал ее, остался недоволен. Слишком плоско. Слишком абстрактно. Главного я тогда не сформулировал.
Меня зовут Александр Козуб и я уже двадцать лет в финтехе, последние несколько из них в качестве CPO. Специализируюсь на ситуациях, когда очевидные рычаги роста уже не работают, и нужны системные решения, а не новые фичи. В симптомах вижу систему, об этом и пишу
Эта статья представляет вторую попытку, и в ней я попробую разложить то, чего в первой не было: механизм. То, как именно добросовестная продуктовая работа методично сужает рамку возможного у тех, кто ее делает.
Снова и снова возвращаюсь в одну и ту же точку. Мне становится скучно на работе в найме. Работаешь несколько лет в одной компании, меняешь команды и проекты в надежде, что что-то изменится. Не помогает — меняешь компанию и роль. Но потом все возвращается на тот же круг. Можно назвать это выгоранием, но это слишком широкое понятие. Я захотел копнуть чуть глубже.
Размышления на тему куда катится вайбкодинг и прочие агентские разработки. Хотите я прочитаю эту статью за вас?
Представьте себе «Матрицу» — сервис, в котором защита вроде бы существует, но каждый ее механизм живет отдельно от остальных.
Для действий используется подписанный токен, для нарушителей предусмотрен бан, для абуза предусмотрен abuse_ban. Только один обработчик проверяет токен, другой выполняет то же действие без него, а ранее выданный PHPSESSID продолжает работать после блокировки анкеты.
В первоначальной структуре внутренними айди записей служили Telegram ID. Также несогласованные проверки в разных PHP-файлах и открытый test.php, который перечислял версии библиотек, абсолютные пути и доступные функции бэкенда.
Статья о том, как решить проблему «забывчивости» LLM между AI-сессиями разработки. Рассматривается причина деградации контекста и предлагается практический подход с использованием ai_readme файлов и агентских хуков, которые принудительно возвращают модель к важным инструкциям. Материал ориентирован на опытных промт-инженеров и показывает, как повысить стабильность и качество генерации кода в реальных больших проектах и при больших контекстных окнах.
Ценность квалифицированного программиста смещается в сторону умения проводить обзоры кода. Генерировать код становится проще, но всё так же важно проверять его с точки зрения качества декомпозиции, корректности реализации, эффективности, безопасности. Посмотрим на примере маленького проекта markus, созданного с помощью Claude Opus, почему важно понимать сгенерированный код и уметь видеть, что скрывает красивый текст программы.
