Фигня.
Не нужно никаких сычуаней, индусов, вайбов и клаудов.
Не нужно даже кафе, стартапов и санфранцисков.
Разрабов и обедов тоже не нужно.
Официантку, если ничего, можно оставить.
Просто подходишь к любому питонщику, тычешь в произвольное место кода и говоришь:
- Здесь пробел лишний. И скобки не хватает.
И там обязательно будет лишнее и будет не хватать.
Профит.
Ты прекрасен.
История дня случилась в Сан-Франциско. Разраб, а по совместительству и основатель стартапа, вайбкодил на обеде, когда вдруг Claude где-то застрял. Помогла решить проблему неожиданно простая официантка из сычуаньской кафешки.
Самый мем произошел дальше. По словам автора, ребята предложили ей долю в компании, но она сказала, что после «ознакомления с кодом предпочла бы не быть в списке акционеров».
Стыдно за этих вайбкодеров 🤭
@xor_journal
Ребята, давайте серьёзно: насколько роботы нужны в больницах прямо сейчас?
В мире это уже не фантастика. Роботы вроде Moxi или TUG развозят лекарства, бельё и анализы по этажам, освобождая медсестёр от бесконечных походов по коридорам. УФ-роботы дезинфицируют палаты за минуты и убивают бактерии лучше, чем ручная уборка. Хирургические системы da Vinci делают операции с ювелирной точностью — разрезы меньше, кровопотеря минимальная, пациенты быстрее встают на ноги. Есть даже роботы-компаньоны, которые измеряют давление, температуру, напоминают о таблетках и просто общаются с пожилыми пациентами, чтобы те не чувствовали себя одиноко.
В итоге: меньше инфекций, меньше ошибок с лекарствами, персонал занимается людьми, а не беготнёй, и в целом больница работает эффективнее.
А я подумал: зачем ждать, пока такие роботы доедут до наших больниц? Взял и начал собирать своего простого робота-помощника. Он должен автономно ездить по палате, возить лёгкие грузы (лекарства, воду), измерять температуру бесконтактно, сопровождать до палат. Ничего сверхъестественного, но уже реально полезно для рутинных задач.
Вот видео сборки — от 3D-печати до прошивки и первых тестовых заездов. Всё на коленке, из доступных деталей.
Что думаете, такие самодельные (а в перспективе и промышленные) роботы реально нужны в российских больницах? Помогут разгрузить персонал или пока рано/дорого/не нужно?
Вк:
Ютуб:
Я человек, который абсолютно не умеет программировать, но с появлением Cursor стало интересно попробовать что-нибудь навайбкодить.
Моим первым проектом стал довольно простой сайт, который помогает найти торговый центр, который лучше всего подходит именно вам. Вы вводите названия магазинов, которые хотите посетить, а система показывает ТЦ с наибольшим количеством совпадений.
Если интересно потыкать — вот ссылка: https://mallio.ru/
Пока доступны Москва (15 ТЦ) и Санкт-Петербург (3 ТЦ). Со временем буду добавлять новые города и торговые центры.
Я собрал базу данных, арендовал VPS, задеплоил проект и начал тестирование. Сначала всё шло хорошо, но в какой-то момент я начал замечать, что база данных просто исчезает. Я делаю миграцию — всё работает, проходит какое-то время и снова ручки начинают пятисотить.
Долго не мог понять, в чём проблема. Тем более что раньше у меня был Telegram-бот с ровно таким же функционалом, на том же хостинге, и никаких проблем не возникало.
Покопавшись в логах, я обнаружил вот такое сообщение:
LOG: statement: DROP DATABASE (название бд);
Оказалось, что у меня были открыты внешние порты для подключения, и кто-то просто подключился к базе данных. Периодически они дропали мою БД и оставляли сообщение с вымогательством денег за типо восстановление данных. А все потому, что Cursor поставил пароль от моей БД - postgres и оставил внешние порты открытыми)))
INSERT INTO readme (text_field) VALUES
('After paying send mail to us: (тут был имейл)
and we will provide a link for you to download your data.
Your DBCODE is: (тут был набор цифр);
Мораль сей басни такова. ИИ — это не панацея и уж точно не полноценная замена разработчику. Я писал промпты про усиление безопасности, но это всё равно не спасло. Базовые вещи вроде сетевой изоляции и нормальных паролей всё ещё лежат на человеке.
Vibe coding это кайф. Накидал промпт, получил код. Пачками выпускаем прототипы.
Топ-менеджмент в компаниях в шоке от того что умеет Bolt, Lovable и т.д.
Но есть проблема это работает пока проект простой. Как только начинаешь делать что-то серьёзнее, допустим SaaS, начинается боль: в одном месте разрабатываешь, в другом ломается, дебажить становится всё сложнее, а контекстное окно заканчивается и почему-то LLM начинает менять стек на ходу и придумывать новые правила.
Конечно в Cursor или Windsurf можно добавлять правила, но они не всегда работают, можно писать к каждому компоненту комменты, но всё равно по мере роста проекта управлять этим всё сложнее.
Ну а как решать то? Поделюсь своим опытом.
Я и в вайбкодинге придерживаюсь продуктового подхода – это когда на каждом этапе жизненного цикла разработки продукта есть ответственный:
Требования пишет продакт, схемы и контракты API описывает аналитик, декомпозирует, дальше разработчик получает техническое описание и начинает работать. Тогда каждый цикл контролируемый и на выходе получаем ожидаемый результат.
В vibe coding такой подход начали называть Spec Driven Development – ну окей, давайте так назовём.
Есть несколько инструментов, которые заменяют мне классический подход
🔹 GitHub Spec Kit по сути копайлот-аналитик. Описываешь что хочешь, он генерит спеку, план, задачи. Агент в IDE понимает что за чем следует. Работает как полноценный воркфлоу: specify – plan – tasks – implement.
🔹 OpenSpec лучше работает, когда уже есть код и надо развивать. Чётко разделяет что уже написано и что меняем. Для существующих проектов удобнее.
У меня качество кода и качество решений выросло в разы. Меньше переделок, меньше "почему оно сломалось". Если пользуетесь чем-то похожим напишите, интересно сравнить.
На предыдущий пост про нашего робота последовала бурная реакция, поэтому мы решили сделать второй — о новой, обновлённой версии робота.
В видео вы увидите, как прошёл наш второй опыт участия в выставке, а также как мы демонстрировали робота губернатору нашей области.
Пожалуйста, посмотрите видео и поделитесь обратной связью — нам очень важно ваше мнение! Мы хотим развиваться в этом направлении и будем рады любым комментариям. 💬
Ютуб:
Вк видео:
IT глазами большинства
Иногда, когда мы рассказываем про Помогизи, люди спрашивают:
— И сколько у вас разработчиков? Наверное, там целый открытый космос айтишников?
И тут мы честно улыбаемся:
— У нас сейчас фронтендер, бэкенд-разработчик, дизайнер, девопс и техдиректор.
Это не армия. Это скорее отряд спецназначения.
Фронтендер — тот самый человек, который отвечает за всё, что вы видите и трогаете: экраны, кнопки, состояния, «ничего не понятно, но очень удобно». Он первый, кто получает от нас запрос: «Сделай, чтобы пользователю было проще и понятнее». Каждая ваша фраза «разобрался без инструкции» — результат того, что кто-то долго переставлял элементы по пикселям.
Бэкенд-разработчик — это тот, кто заботится о том, чтобы за красивыми экранами было на что опереться: платежи, логика, права доступа, статусы, очереди, обработка данных. Пользователь его не видит, но если что-то идёт не так — видно всем сразу. Его работа — сделать так, чтобы система не развалилась в самый важный момент.
Дизайнер — человек, который переводит наши хаотичные мысли «хотим, чтобы было приятно и не страшно» в конкретные интерфейсы. Он балансирует между продуктом, разработкой и пользователем. Где-то сдерживает наш креатив, где-то наоборот заставляет сделать красиво там, где мы бы сказали «и так сойдёт».
Девопс — тот, кто спит в обнимку с серверами. Пока все остальные говорят про фичи (функции приложения), он думает, как сделать так, чтобы всё это работало быстро, безопасно и стабильно. И если вдруг что-то падает ночью, велика вероятность, что он уже всё чинит, пока вы только пишете: «У вас ничего не работает…».
И, наконец, технический директор — тот человек, кто собирает всё это в общую техническую картину: какие технологии мы выбираем, как они будут жить через год, куда растёт архитектура, что можно запускать сейчас, а что лучше не трогать, пока не готовы.
Пока мы не можем похвастаться большим штатом разработчиков. Но их квалификация и мотивация делает нас супер-командос. Каждый аспект приложения мы стараемся прожевать заранее.
Маленькая команда — не минус, если у неё есть одна навязчивая идея. Делать не «лишь бы работало», а так, чтобы не было стыдно ни перед пользователями, ни перед теми, кому эта помощь реально нужна.
Реклама ООО «ЮНИК», ИНН: 7751240810
Последние пару недель занимаюсь унификацией технологического стека для всех своих pet-проектов и поделок. Цель — собрать единый тех-радар, чтобы не тратить время на переключение контекста между разными фреймворками и библиотеками.
Frontend:
- React (без сюрпризов)
- WXT (лучший фреймворк для браузерных расширений)
- MUI (библиотека UI-компонентов под Material Design)
- Netlify (бесплатный и надёжный хостинг)
Backend:
- Supabase (как Firebase, только лучше)
- Yandex Cloud (serverless-контейнеры + S3-хранилища)
На выходных добрался до Speech to Text — браузерного расширения для транскрипции аудио. Оно было написано на vanilla JS ещё в первых версиях, и каждое обновление превращалось в квест по поиску багов и зависимостей.
С помощью Cursor (AI-ассистента для кода) переписал всё расширение за пару часов:
Перенёс на WXT (фреймворк для Chrome Extensions)
Заменил самописные компоненты на MUI
Добавил TypeScript для типобезопасности
Заодно запилил новую фичу: транскрипцию системного звука через Chrome Tab Capture API
Теперь Speech to Text может расшифровывать не только микрофон, но и всё, что играет на компьютере: YouTube-видео, Zoom-созвоны, лекции, подкасты и т.д.
Дополнительно добавил:
Аудиоплеер для предпросмотра файла перед отправкой
Анонимную расшифровку по прямой ссылке на аудио
Модерация в Chrome Web Store прошла за 2 часа (обычно было 8-12). Предполагаю, что регулярные релизы дают "репутацию" у алгоритмов Google.
Унификация стека — это не просто модное слово, а реальная экономия времени. Теперь могу быстро переключаться между проектами и переиспользовать компоненты без головной боли.
Хотите больше деталей?
Про процесс унификации стека, выбор инструментов и другие эксперименты с расширениями пишу в своём Telegram-канале @debug_leg. Там более неформальный формат: короткие посты, скриншоты процесса и честные истории про грабли. Подписывайтесь, если интересна кухня разработки.
