В статье про устройство этого блога я рассказал, что мы сделали его за три дня, и признался: без ИИ-помощника такой темп был бы невозможен. Тогда я пообещал отдельную статью о том, почему считаю, что разработка без ИИ-инструментов — путь в никуда. Вот она.
Год назад я бы с этим спорил
Скажу честно: ещё год назад я согласился бы с разработчиком, который называет ИИ баловством. Тогда ИИ просто не умел того, что умеет сейчас. Пользы от него было меньше, чем возни с ним.
Сейчас ситуация другая. В работе я пользуюсь в основном Claude, и он стал полноценной частью моего рабочего процесса. Но не заменой мне, а ускорителем. Разницу между этими словами я и хочу объяснить.
Что я отдаю ИИ
Задачи, которые я спокойно отдаю, делятся на три группы.
- Рутина. Покрыть код тестами, написать первую версию сценария развёртывания приложения в Jenkins, подготовить типовые части проекта. Это работа, которую нужно сделать хорошо, но которая не требует принимать важных решений.
- Исследования. Разобраться, как устроен чужой код, найти, где возникает ошибка, сравнить варианты решения.
- Аналитика. Разобрать большой объём данных, найти в нём закономерности и ошибки.
Хороший пример — импорт больших файлов. Допустим, в систему нужно загрузить большие Excel-таблицы. Внутри данные могут быть расположены по-разному: где-то сдвинуты колонки, где-то перепутан формат, где-то просто ошибки. Раньше на то, чтобы разобраться в такой таблице, уходило много ручного времени. Теперь ИИ быстро находит ошибки, структурирует данные и приводит их к одному виду, а дальше я пишу код импорта уже по понятной структуре.
Второй пример — документация API. Раньше мы вели её, честно говоря, на минималках: основные запросы описаны, остальное — «посмотри в коде». Теперь эту задачу получает Claude и описывает все возможные ответы и все модели данных. Это не просто аккуратность ради аккуратности: подробная документация ускоряет все следующие этапы разработки, потому что фронтенд-разработчику и тестировщику не нужно гадать, что вернёт сервер.
Что я не отдаю никогда: архитектуру
Архитектуру проекта я продумываю только сам. И у меня есть история, которая хорошо показывает почему.
На одном проекте я решил попробовать: дал Claude задачу продумать архитектуру. Он продумал, но его подход мне не понравился. Мы обсудили, и я зафиксировал свой вариант. Начали первую задачу, и что я вижу: он сделал её примерно наполовину по своему подходу, наполовину по моему. Когда я указал на это, ответ был в духе: «Да, вы правы, я забыл».
Ошибка мелкая, её легко поймать. Но представьте проект, где проверять некому. Через месяц в коде будут жить две архитектуры одновременно, и каждая новая функция будет ломать что-то в другой части.
При этом я не читаю каждую строку, которую написал ИИ. Глубина проверки зависит от задачи. Рутину часто достаточно проверить по результату, а изменения в важной логике я смотрю внимательно. Понимать, где можно доверять, а где нужно смотреть внимательно, — это и есть опыт, который ИИ не заменяет.
Где ИИ работает у нас сейчас
ИИ использую не только я.
- В Parfumart с помощью ИИ анализируют данные: заказы, звонки и другие показатели.
- В ИН-ЖИР мы используем ИИ везде, где он помогает: от составления отчётов клиентам до программирования.
Этот блог — тоже пример. Три дня от пустых репозиториев до работающего сайта получились потому, что архитектура и решения были на мне, а большая часть рутины — на ИИ.
Почему без ИИ — путь в никуда
Вот главный аргумент. Представим двух разработчиков. Первый очень сильный, но работает по старинке и выпускает условно одну задачу в неделю. Второй тоже хороший специалист, но работает с ИИ и выпускает двадцать.
Даже если у второго качество чуть ниже, разрыв в скорости уже не перекрыть. Пока первый пишет метод, чтобы проверить какую-то гипотезу, второй её уже проверил, получил вывод и двигается дальше. Бизнесу нужен результат, и клиенты будут уходить к тем, кто даёт его быстрее.
Поэтому разработчику, который до сих пор считает ИИ баловством, я бы сказал: вы ошибаетесь. ИИ не заменит вас. Он позволит вам выйти на новый уровень: меньше времени на рутину, больше на то, что действительно требует головы.
Обратная сторона: вайбкодеры
Есть и другая крайность. Появились люди, которые ничего не понимают в разработке, но с помощью ИИ собирают что-то похожее на работающий продукт и называют себя разработчиками. Это и есть вайбкодинг: код пишет ИИ, а человек не понимает, что именно получилось.
Пока проект маленький, это может даже работать. Но как только появляются реальные пользователи, деньги и нагрузка, такой код начинает разваливаться, а исправить его некому. Клиент остаётся с продуктом, который нельзя развивать, и с плохим впечатлением о разработчиках вообще.
И вот это меня беспокоит больше всего. Из-за таких историй к разработчикам начинают относиться как к строителям из анекдотов: заранее не доверяют, ждут обмана и сорванных сроков. Страдают от этого все, включая тех, кто делает свою работу честно.
Как бизнесу выбрать подрядчика
Если вы выбираете команду для своего проекта, вопрос «используете ли вы ИИ» уже не главный. Правильный ответ на него — «да». Важнее другое:
- Кто отвечает за архитектуру? Должен быть конкретный человек, который понимает систему целиком и может объяснить, почему она устроена именно так.
- Как проверяется результат? Тестовые стенды, тестирование перед выкладкой, понятный процесс. О том, как это устроено у нас, я рассказывал в истории Parfumart.
- Может ли команда объяснить свой код? Если на вопрос «как это работает» вы слышите неуверенное «ну, оно работает», это повод насторожиться.
Итог
ИИ не делает плохого разработчика хорошим. Он делает хорошего разработчика в разы быстрее. Отказываться от него сегодня — значит добровольно проигрывать в скорости. Доверять ему всё без понимания — значит проигрывать в качестве. Выигрывает тот, кто держит архитектуру и ответственность в своих руках, а рутину отдаёт ИИ.
Если хотите обсудить, как ускорить разработку вашего проекта и не потерять в качестве, напишите мне. А чтобы не пропускать новые статьи, подписывайтесь на канал в Telegram или Max.
