6 месяцев. Это сколько мы строили продукт с внешним разработчиком. Потом я психанула и сделала за 3 дня сама с помощью AI. Дальше — что я поняла из этого опыта.
Эта статья — не «AI заменит разработчиков». Это про другое — про то, как методология работы меняется, когда у тебя есть AI как партнер.
Производственник, который пришёл в IT. О том, почему до кода надо идти в цех.
Несколько лет назад наблюдал проект на одном производственном предприятии. Небольшое производство, человек 200. До нашего проекта руководство уже наняло специалистов 1С и начало автоматизировать учёт движения сырья и управленческую отчётность по сменам. Кто‑то посоветовал — мол, пора двигаться к нормальному учёту.
В эпоху вайбкодинга удивить кого‑то базовым веб‑интерфейсом сложно. Но сделать его понятным и простым в поддержке — другой вопрос. Если вы хотите обернуть свои скриптыавтоматизацию в красивую обертку, а также сделать это быстро и просто — я нашел для вас классную библиотеку на python.
Цель статьи — поделиться классным инструментом и замотивировать вас к созданию нового. Поехали!
Дисклеймер: я продакт, не разработчик. Тех. бэкграунд — теоретический. Эта статья про то, как выглядит вайб-кодинг глазами PM и что реально работает, а не что обещает маркетинг.
У большинства продактов, которые хотят запустить что-то своё, есть один и тот же потолок: нет команды → нет продукта. Найм, онбординг, выстраивание процессов, ожидание первых релизов — это месяцы и деньги ещё до первой проверки гипотезы.
Последнюю неделю я тестировал, насколько этот потолок реален в 2025 году. Результат — два живых проекта:
личный сайт по продуктовому консалтингу
Раньше я был технологическим предпринимателем в России, а сейчас — буддийский монах.
Я продуктовый дизайнер с 7-летним стажем. За последний месяц я в одиночку запустил 9 цифровых продуктов — без разработчиков, тестировщиков и девопсов. И самое странное: лучший результат я получил, когда перестал делать то, в чём разбираюсь.
Привет, я Лена, это мой первый пост здесь, и он про техническую задачу, с которой мы столкнулись: как заставить LLM писать текст так, чтобы его нельзя было отличить от написанного конкретной редакцией. Не «хороший текст», не «грамотный текст», а такой, который звучит как этот конкретный городской портал или этот Telegram-канал.
Тестирование в разработке — вещь настолько привычная, что о его важности обычно даже не спорят. Если продукт развивается, появляются новые функции, интерфейсы меняются, пользовательские сценарии усложняются — без тестирования всё это быстро превращается в хаос.
А вот пользовательская документация живёт куда более сложной жизнью. Её либо не пишут вовсе, надеясь на хороший UX, либо пишут один раз и больше к ней не возвращаются. Через несколько месяцев оказывается, что интерфейс уже другой, кнопки переехали, а скриншоты выглядят как привет из прошлого релиза.
