README.md

ИИ резко снизил порог входа, cейчас похожий сервис может за пару недель собрать компания конкурент или один человек с подпиской на Claude Code.

Просто "сделать" больше недостаточно, посредственно сделать теперь могут все.

Я делаю ставку на качество как конкурентное преимущество. Продукт должен быстрее открываться, понятнее вести себя при ошибках, нормально работать на телефоне, не ломать привычные сценарии и не раздражать в первые минуты.

Я активно использую ИИ, просто не отношусь к нему как к магии.

ИИ хорошо ускоряет работу, когда им управляет человек, который понимает продукт и код. Я веду агентов как дополнительную команду, ставлю задачи, проверяю результат, заставляю переделывать слабые места и смотрю, чтобы код оставался человеческим.

Без такого контроля скорость быстро превращается в техдолг. Это довольно скучная мысль, но она постоянно подтверждается на практике.

Для меня ИИ скорее усилитель. До автопилота ему ещё далеко.

Я часто нахожу инженерные приёмы/лайфхаки, которые экономят бюджет и сроки без потери функциональности.

Где-то задачу можно чуть иначе поставить. Где-то взять готовую часть вместо новой разработки. Где-то сделать маленькую утилиту вместо системы, которую потом ещё поддерживать. А бывает, что фичу лучше вообще не делать, потому что она тянет месяц работы и почти ничего не даёт пользователю.

Это такое инженерное читерство в хорошем смысле.

Писать код мало. Нужно понимать цену решения.

Код продукта задаёт цену будущих изменений.

Я отношусь к техдолгу буквально как к долгу у себя в будущем. Сегодня взял время взаймы, потом вернёшь с процентами. Иногда так можно, иногда даже нужно, но хорошо бы понимать, сколько процентов набежит.

Я смотрю на цену ошибки. Что сломается. Кто будет чинить. Сколько будет стоить переделка. Насколько больно будет подключить нового человека.

Часть хорошей инженерной работы выглядит скучно, потому что плохого просто не случилось.

Это не выглядит как подвиг, ну и хорошо.

К коду у меня прагматичное отношение. Красивая архитектура нужна, если она помогает продукту жить дольше и спокойнее. Иногда правильная абстракция экономит месяцы, а иногда она связывает части системы, которым лучше оставаться отдельными.

Главное, чтобы решение отвечало за свою цену.

Продукт должен быть собран целиком.

Пользователь не разбирает, где закончился backend и начался frontend. Он не думает "ну, метаданные не настроили, зато бизнес-логика хорошая". Он просто открывает сервис и чувствует, нормальная это вещь или собрана кое-как.

Мне помогает опыт собственных проектов. Когда сам проходишь путь от идеи до запуска, поддержки и маркетинга, начинаешь смотреть не на отдельный тикет, а на весь цикл.

Я такие вещи замечаю.

Проверяю обычные сценарии руками. Открываю сервис с телефона, возвращаюсь назад, обновляю страницу, смотрю ошибки, пустые состояния, первую загрузку. Это быстро показывает, насколько продукт на самом деле доделан.

Я начинал как дизайнер, а потом много лет превращал чужие макеты в живые продукты. Эта насмотренность до сих пор помогает.

Макет в Figma часто неподвижный, в приложении же есть загрузка, ошибка, пустое состояние, переход, микровзаимодействия, анимации, звуки, вибрации и т.д.

Не всегда есть ресурс нарисовать каждое состояние заранее. Тогда я доделываю по месту, это уже вошло в привычку. Сначала делаю понятное состояние кнопки, добавляю небольшую анимацию, проверяю, чтобы не лагало, спрашиваю дизайнера, если надо.

Мне близка идея MLP. Даже минимальная версия продукта должна быть такой, чтобы ей хотелось пользоваться, иначе это просто техническая проверка гипотезы, а не нормальный первый контакт с рынком.

Из этого часто и складывается ощущение качества.

Если у вас уже есть команда, я могу усиливать её через обычную работу.

Большой процесс вокруг этого не обязателен. Часто хватает ревью, совместной работы, нормального разбора решений, помощи с постановкой задач и неформального общения в перерывах.

Мои компетенции частично перенимаются и становятся общими.