Урок
1.1 Вступление. Для кого этот гайд и почему он нацелен на приватную и корпоративную разработку при помощи LLM?
Привет, друзья! Я сделал себе новый блог и решил начать с самой актуальной на сегодня темы - это продуктовая разработка с ИИ. Данный гайд нацелен на широкую аудиторию, на обычных разработчиков, на начинающих свой путь в программировании и на тех, кто последние несколько лет спал и ИИ не интересовался особо. Постараюсь кратко и емко разжевать все важные аспекты и поделиться рецептами и инструментами, как писать поддерживаемый и расширяемый код, готовый к production, и понятный человеку.
Почему мы будем ориентироваться на корпоративные стандарты написания кода?

Когда вы занимаетесь вайбкодингом и пилите свое приложение - вы ограничены только теми рамками, которые вы сами себе задаете. И все проблемы, которые у вас будут возникать при развитии вашего проекта - это только ваша боль.
Если взять любую продуктовую компанию, где больше одного разработчика, то без настроенных процессов разработки, продукт с каждым месяцем по экспоненте будет превращаться в хаотичное, неподдерживаемое дерьмо. Страдать будут все: разработчики, тестировщики и пользователи.
В корпоративной среде есть определенные требования к продукту и к разработке:
Единый стиль написания кода, задокументированный в Code Style Guide
Возможность быстрой замены одного сотрудника другим и быстрое погружение в проект, хранение знаний по проекте
Каждая, даже самая маленькая задача, должна проходить многоступенчатый процесс приемки и проверки качества, состоящий из ИИшного и человеческого ревью и тестирования
Большой список требований на всех этапах разработки и тестирования
Обеспечение более-менее предсказуемого результата всеми доступными способами
Как вы наверное уже поняли, мы будем строить систему, которая позволит получать предсказуемый результат и поможет без боли в заднице долгосрочно работать над продуктом.
Я бы хотел реализовать такой флоу разработки, который будет эффективным, как для одного человека, так и для целой команды. В поисках волшебной пилюли, мы попробуем разные подходы и разные методики. Будет весело!
Проблемы облачных моделей по подписке
Нас буквально подсадили на облачные модели, это удобно и пока относительно недорого.
Самая главная проблема - эта ваша зависимость от сторонней инфраструктуры. Одно политическое решение - и вас могут лишить инструмента, к которому вы привыкли и без которого уже не представляете свою работу. Под соусом санкций или любым другим.
Вторая проблема - это нестабильная работа и черный ящик под капотом. Если вы много работаете с облачными LLM, например Claude Code или Codex, вы стопудово замечали периодически огромное падение скорости генерации в часы пик. Но, страшнее другое, у вас может быть включен Claude Opus, а по факту работать супер-слабая модель в низком режиме effort, и те задачи, которые выполнялись за один-два промта, теперь не выполняются вовсе. В такие моменты вы не можете выполнять свои рабочие задачи, как раньше и с той же скоростью. И вы тут никому ничего не сможете предъявить.
Плати и не выебывайся!
Также многие пользователи с Реддита постоянно замечают, что с выходом новой модели старые модели сильно тупеют. Есть хорошая статья на эту тему - https://habr.com/ru/articles/1023020/
Третья проблема - это приватность. Если вы из тех людей, "кому нечего скрывать", то я вас поздравляю! Любое государство - это супер-система, где каждый год штампуются законы, позволяющие все глубже залезать вам в трусы и использовать уже собранную информацию, чтобы забрать ваши деньги и свободы. И вы будете первыми на прицеле. С ИИ этот процесс сильно ускорится. Если говорить про коммерческие компании - то тут риски сильно возрастают. Где много денег - там много внимания от разных участников из разных структур и также желающих завладеть ресурсами. И если вы верите, что данные, передаваемые в Anthropic и OpenAI, никому недоступны - вы очень наивны. Это информация очень высокой ценности, предоставляемая добровольно.
Преимущества локальных открытых моделей на примере Qwen 3.6 27B

Самое большое преимущество - это стабильная работа и утром и днем и ночью. Модель не тупеет в вечерние часы, скорость всегда одинаковая.
Разумеется, локальные модели не такие умные, как гигантские облачные. Но, тут тоже есть неочевидный плюс. Вы более тщательно планируете задачу, разбивая ее на более мелкие, с которыми справится даже очень глупая модель. Вы не сможете беспощадно вайбкодить, вам придется взаимодействовать с ней, как инженер, зная слабые места. За счет этого вы будете писать код более осознанно.
Я утверждаю, что модели Qwen 3.6 27B вполне достаточно для качественной продуктовой разработки. Это плотная модель и у нее одновременно работают все 27B параметров. И ее можно запустить локально на видеокарте с 32 Gb VRAM или на Mac с Unified memory.
Я проводил эксперимент. У меня была задача для одного проекта внедрить темную тему. Я сначала использовал Qwen 3.6 27B, а потом GPT 5.6 Sol. То есть два раза сделал одну и ту же задачу разными моделями. На каждую реализацию у меня ушло примерно по 2 часа. Результат получился похожий. Но мне больше понравилось работать с Qwen - он пошустрее писал код и не тупил периодчески. Результат - пул-реквест со 110 измененными файлами . Руками, без ИИ, эта задача заняла бы примерно 5 рабочих дней.
Буст космический! Идем дальше!
