Как стать крутым вайбкодером? 🦄🔧
Недавно я делился ссылкой на статью с подробным объяснением того, как пользоваться Claude Code. Этот инструмент не заменяет людей с техническим мышлением и опытом программирования, а расширяет их возможности. И, что не менее важно, даёт техническому Product Manager возможность строить качественный продукт без full-time команды разработки.
В дополнение хочу поделиться несколькими советами о том, как строить качественные продукты с правильной архитектурой, а не одноразовые заготовки.
1. Следуйте правилам Software Engineering
Есть онлайн-книга и свод правил о том, как правильно строить IT-продукты: https://lawsofsoftwareengineering.com/
Они основаны на здравом смысле и опыте очень умных людей: некоторые из них теряют актуальность, а некоторые, наоборот, очень полезны в работе над любым продуктом.
Для вашего удобства я преобразовал советы в .md файл, адаптированный под LLM, — его можно использовать как часть контекста локально, чтобы Claude не писал лишний код и правильно принимал решения. Google Drive: https://drive.google.com/file/d/1K2xjdLtWXsqLeQ3QIlr8ro8AZizuGXo0/view?usp=sharing
2. Используйте готовые решения в качестве основы
Например, для SaaS возьмите SupaStarter (https://supastarter.dev/) с уже готовой проверенной кодовой базой; для универсальных продуктов — PayloadCMS (https://payloadcms.com/); для контентных сайтов и части eCommerce подойдёт Laravel с модулями (но первые два варианта всё-таки лучше).
Это позволит вам при необходимости привлечь инженера на популярный стек, в котором основной код оптимизирован, задокументирован, а принцип работы понятен с ходу.
3. Разделяйте стенды на Dev / Test / Prod
Это очевидно для любого разработчика или технического директора, но новички часто льют напрямую в Prod и потом удивляются, почему всё сломалось.
У вас должно быть три стенда: один — для активной разработки, второй — для тестирования продукта перед выкаткой, и основной, где прямо сейчас работают пользователи.
4. Используйте лицензионные, но нестандартные шрифты 🎨
Видеть однообразные Claude-шрифты для меня небольшая боль!
Самое простое — как минимум выбрать подходящий шрифт на https://fonts.google.com/ и подключить его одним промптом.
5. Продукт должен быть простым
Не расширяйте продукт до 10–15 экранов и нескольких ключевых функций со старта. Чем проще и понятнее продукт — тем лучше.
Исключений очень мало, и, к сожалению, по моему опыту все попытки раздуть MVP ведут к большим проблемам (это всё описано в Laws of Software Engineering тоже).
💼Для больших команд самый главный совет: используйте только актуальный контекст который будет расширяться сам!
Confluence, Slack, Jira, комментарии в коде и сам актуальный код должны быть частью AI-инфраструктуры. Мы пока на пути к тому, чтобы это заработало правильно, но именно от контекста зависит адекватность решений которые вы будете создавать с AI.
Недавно я делился ссылкой на статью с подробным объяснением того, как пользоваться Claude Code. Этот инструмент не заменяет людей с техническим мышлением и опытом программирования, а расширяет их возможности. И, что не менее важно, даёт техническому Product Manager возможность строить качественный продукт без full-time команды разработки.
В дополнение хочу поделиться несколькими советами о том, как строить качественные продукты с правильной архитектурой, а не одноразовые заготовки.
1. Следуйте правилам Software Engineering
Есть онлайн-книга и свод правил о том, как правильно строить IT-продукты: https://lawsofsoftwareengineering.com/
Они основаны на здравом смысле и опыте очень умных людей: некоторые из них теряют актуальность, а некоторые, наоборот, очень полезны в работе над любым продуктом.
Для вашего удобства я преобразовал советы в .md файл, адаптированный под LLM, — его можно использовать как часть контекста локально, чтобы Claude не писал лишний код и правильно принимал решения. Google Drive: https://drive.google.com/file/d/1K2xjdLtWXsqLeQ3QIlr8ro8AZizuGXo0/view?usp=sharing
2. Используйте готовые решения в качестве основы
Например, для SaaS возьмите SupaStarter (https://supastarter.dev/) с уже готовой проверенной кодовой базой; для универсальных продуктов — PayloadCMS (https://payloadcms.com/); для контентных сайтов и части eCommerce подойдёт Laravel с модулями (но первые два варианта всё-таки лучше).
Это позволит вам при необходимости привлечь инженера на популярный стек, в котором основной код оптимизирован, задокументирован, а принцип работы понятен с ходу.
3. Разделяйте стенды на Dev / Test / Prod
Это очевидно для любого разработчика или технического директора, но новички часто льют напрямую в Prod и потом удивляются, почему всё сломалось.
У вас должно быть три стенда: один — для активной разработки, второй — для тестирования продукта перед выкаткой, и основной, где прямо сейчас работают пользователи.
4. Используйте лицензионные, но нестандартные шрифты 🎨
Видеть однообразные Claude-шрифты для меня небольшая боль!
Самое простое — как минимум выбрать подходящий шрифт на https://fonts.google.com/ и подключить его одним промптом.
5. Продукт должен быть простым
Не расширяйте продукт до 10–15 экранов и нескольких ключевых функций со старта. Чем проще и понятнее продукт — тем лучше.
Исключений очень мало, и, к сожалению, по моему опыту все попытки раздуть MVP ведут к большим проблемам (это всё описано в Laws of Software Engineering тоже).
💼Для больших команд самый главный совет: используйте только актуальный контекст который будет расширяться сам!
Confluence, Slack, Jira, комментарии в коде и сам актуальный код должны быть частью AI-инфраструктуры. Мы пока на пути к тому, чтобы это заработало правильно, но именно от контекста зависит адекватность решений которые вы будете создавать с AI.