Нейросеть для программиста: что реально ускоряется

Короткий ответ: ускоряется написание, не ускоряется приёмка. Код появляется в разы быстрее, а прочитать и принять его надо ровно так же внимательно, как раньше. Значит узкое место переезжает — и выигрыш получают там, где приёмка дешёвая.

Из этого выводится почти всё остальное, включая список задач, где браться не стоит.

Где выигрыш подтверждается

Незнакомый язык или библиотека. Модель знает синтаксис, которого не знаете вы, а проверить результат можно запуском. Здесь ускорение максимальное и риск минимальный.

Однообразный код. Формы, миграции, преобразования данных, обвязка вокруг вызовов. Проверяется просмотром, ошибки видны сразу.

Разбор чужого кода. Не написать, а объяснить: что делает этот модуль, где он вызывается, что сломается при изменении. Проверка дешёвая — можно перепроверить в двух местах.

Тесты к существующему коду. Модель хорошо видит границы и пограничные случаи, а тест либо проходит, либо нет.

Разовые скрипты. Разбор выгрузки, переименование, миграция данных. Живут один день, проверяются результатом.

Где выигрыш мнимый

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

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

Большие изменения одним куском. Дифф на восемьсот строк не проверяют, его одобряют. Это не проверка, это её имитация.

Что меняется в работе команды

Дифф становится главным артефактом. Раньше его размер определялся тем, сколько человек успел написать. Теперь ничем не ограничен — значит ограничивать надо сознательно. Порог, за которым проверка вырождается в одобрение, у каждого свой, но он есть.

План важнее кода. План читается за минуту, дифф — за час. Самая дешёвая точка вмешательства сместилась в начало.

Ответственность не переезжает. За результат отвечает тот, кто его принял, — кто отвечает, если работу сделал агент.

Именование начинает влиять на скорость. Агент читает ваш код как контекст: имя, которое врёт, сбивает его надёжнее, чем отсутствие имени.

Что стоит настроить до, а не после

Файл правил проекта. Команды сборки, запреты, границы. Без него каждый разговор начинается с объяснения одного и того же.

Черновик в файл, а не в чат. В чате нет диффа, и на третьей итерации проверка вырождается в доверие — почему это важно.

Подтверждение необратимого. Список короткий: удаление, отправка наружу, публикация, деньги. Спросить дешевле, чем откатить.

Условие несогласия

Всё сказанное — про работу в существующей системе. Для нового проекта с нуля картина другая: приёмка дешевле, потому что ломать нечего, и выигрыш заметно больше.

Обратный край — унаследованный код без тестов. Там приёмка настолько дорогая, что ускорение написания не даёт ничего: узкое место было и остаётся в проверке.

Чего я делать не стал бы

Не стал бы измерять эффект в строках или в скорости появления кода. Это метрика того шага, который перестал быть узким.

Не стал бы принимать код, который не могу объяснить. Формулировка простая: если не получается своими словами сказать, что делает эта функция и почему так, — принимать нельзя, независимо от того, кто её написал.

Не стал бы отключать проверки ради скорости. Именно они переносят выигрыш из «быстрее написали» в «быстрее выпустили».

Открытый вопрос

Тревожит не качество кода, а то, что происходит с инженером через полгода в роли приёмщика. Навык чтения растёт, навык написания не тренируется — а способность принять решение о чужом коде опирается на опыт написания своего.

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