Мой GitHub-график за 2025 год выглядит так, будто его заполняли два разных разработчика. Первая половина года почти пустая. Во второй — более 4000 коммитов.
Свободного времени у меня внезапно больше не стало. Я всё так же совмещал фултайм-работу с сайд-проектами. Изменилось другое: расстояние между идеей и первой работающей версией стало проходить заметно легче, потому что я начал гораздо серьёзнее использовать AI-инструменты для разработки.
Здесь важно не переоценивать красивую цифру. Количество коммитов само по себе не является метрикой продуктивности. Четыре тысячи коммитов не доказывают, что я сделал четыре тысячи полезных улучшений или что весь код был хорошим. Но график действительно показывает изменение моего рабочего ритма: я стал гораздо стабильнее строить, переделывать и доводить проекты до работающего состояния.
Настоящим узким местом была энергия на старт эксперимента
В сайд-проектах я снова и снова упирался в одну проблему: первая полезная версия часто находится за стеной рутинной работы. Routing, validation, скрипты, тесты, конфигурация и cleanup могут съесть импульс ещё до того, как становится понятно, стоит ли идея дальнейшей разработки.
Раньше я откладывал эксперименты, если первый рабочий вариант выглядел как несколько вечеров подготовительной работы. AI coding не убрал эту работу, но снизил стоимость первого прохода и сократил путь до версии, которую уже можно проверить.
Поэтому главным выигрышем для меня была не скорость печати. Важнее оказалось снижение порога входа: больше идей вообще доходили до стадии, где по ним можно получить реальные данные.
Как изменился мой Node.js workflow
Я не заменил разработку окном чата. В Node.js-сайд-проектах я использовал DeepSeek как вторую пару рук для узких задач: набросать первую реализацию, разобраться в незнакомом участке кода, предложить тесты, разобрать stack trace, разбить большой refactor на маленькие шаги и проверить assumptions вокруг deployment.
- Scaffolding: сделать скучную первую версию handler'ов, validation, scripts или tests.
- Code reading: проследить путь request или значения до начала изменений.
- Refactoring: разложить механические изменения на маленькие проверяемые diff'ы.
- Debugging: получить несколько конкурирующих гипотез по logs, а не цепляться за первую.
- Verification: найти edge cases и regression-сценарии после того, как заработал happy path.
Чем яснее были inputs, outputs, ограничения и существующие conventions, тем проще было проверить результат. Размытые задачи чаще давали правдоподобную, но неверную abstraction.
Поэтому любой AI-output я воспринимал как candidate patch, а не как готовый ответ. Type checking, tests, production build и реальный пользовательский flow были доказательствами; уверенный текст модели — нет.
Где DeepSeek помогал больше всего — и где не помогал
DeepSeek оказался удобен тем, что его можно было много раз использовать на конкретных программных задачах: получить first pass, отбросить часть решения, вернуть реальную ошибку, сузить scope и быстро повторить цикл.
Я не называю это бенчмарком. Я не проводил контролируемое сравнение со всеми конкурентами, а линейки моделей быстро меняются. Корректное утверждение намного уже: DeepSeek достаточно хорошо подошёл моему workflow, чтобы я стал использовать AI assistance намного чаще.
Лучше всего он работал там, где обратная связь дешёвая: есть функция, тесты и конкретная ошибка. Хуже — когда задача зависит от неописанного продуктового контекста или тонких архитектурных trade-offs. В таких случаях гладкий ответ может сделать плохое предположение похожим на готовое решение.
AI изменил стоимость эксперимента
Главное улучшение для меня было не в логике «AI пишет код, значит разработка теперь автоматическая». Изменилось другое: множество небольших частей стало достаточно дёшево попробовать. Фича для сайд-проекта, которая раньше выглядела как слишком много подготовки, теперь могла превратиться в прототип, пока мне ещё была интересна сама идея.
Это важное различие. AI снизил стоимость пути до версии, которую уже можно проверять. Но архитектура, продуктовые решения, deployment и корректность никуда не исчезли. Сгенерированная реализация всё ещё может быть неправильной; успешный build не гарантирует правильное поведение в runtime; задеплоенный прототип всё ещё может оказаться плохим продуктом.
Для меня практическим преимуществом стал именно импульс. Когда вся система уже работала целиком, мне было гораздо проще продолжать её улучшать.
Что понадобилось бы для более сильного бенчмарка
Для воспроизводимого сравнения я бы фиксировал точные версии моделей, одинаковые programming tasks, snapshots репозитория, prompts, raw outputs, затраченное время, принятые и отклонённые patches, review time, результаты tests и объём rework.
И измерял бы не только commits: время от идеи до проверенной версии, defects, rollbacks и количество переписанной работы. Без этого 4000 коммитов показывают активность и изменение рабочего поведения, но не качество software.
Что для меня изменилось
2025 год стал моментом, когда я перестал воспринимать каждый сайд-проект как гору setup, которую нужно вручную перелезть до начала настоящей работы. AI сделал первую работающую версию достаточно дешёвой, чтобы я чаще добирался до этапа, где уже важны именно продуктовые решения.
Вот почему вторая половина моего GitHub-графика выглядит настолько иначе. Не потому, что AI добавил мне часов в сутках, и не потому, что каждая сгенерированная строка была хорошей. Он снизил трение, из-за которого прежние идеи умирали ещё до того, как становились реальными.
В 2026 году мне интереснее уже менее эффектная половина этой истории: оттачивать workflow, серьёзнее измерять качество и следить за тем, чтобы более быстрая разработка давала лучший софт, а не просто больше коммитов.