Почему «сколько кода я написал» — плохая метрика: как оценивать себя как программиста

Метрика была простая: чем больше кода я могу написать сам, тем лучше я как разработчик.

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

Лет пятнадцать назад на Stack Overflow всерьёз обсуждали, не считается ли автодополнение жульничеством. Люди спрашивали, нормально ли это или «настоящий программист» так не делает. Теперь под рукой инструмент, который пишет функции целиком, и тот же вопрос вернулся, только громче.

Если код написала модель — что построил лично ты?

Я задавал себе этот вопрос чаще, чем хочется признавать. Перестал.

Генерация кода стала лёгкой частью

Опишите идею — получите сотни строк правдоподобного кода почти мгновенно. Иногда он даже работает. Первые несколько раз это выглядит как магия.

Потом вы собираете что-то посложнее, и модель начинает вести себя предсказуемо плохо:

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

Вывод простой: написание кода никогда не было всей работой. Это была лишь самая заметная её часть.

Тяжелее всего — заметить, что что-то не так

С ИИ я стал думать о софте больше. Не печатать, а именно думать. Когда агент выдаёт реализацию, приходится задавать вопросы:

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

И мой любимый: почему это вообще работает? Код, который работает, и код, который вы понимаете, — разные вещи. Не хочу держать в проекте артефакт, выданный оракулом. Если не могу объяснить — пока не доверяю.

Что мерить вместо строк

Отладка и вопрос авторства

Писать код приятно, потому что похоже на прогресс. Отладка проверяет, понимаете ли вы то, что построили. Разница между «ИИ сделал фичу» и «ИИ сделал первую версию, а я нашёл, откуда утекает состояние между компонентами, проследил регрессию, поменял модель владения данными, проверил краевые случаи и убедился, что починено» — огромная.

Второй опыт учит о системе гораздо больше. И в какой-то момент понимаешь: это тоже программирование. Пожалуй, больше — это инженерия. Авторство не в том, чьи пальцы нажимали клавиши. Оно в решениях, в понимании последствий, в отказе от плохих подходов и в выборе того, что останется в коде навсегда.

Помощь давно перестала быть читерством

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

Из-за этого независимость превращается в доказательство профпригодности: раз могу без чужой помощи — значит, я тут не случайно.

Документация — инструмент. Библиотеки, фреймворки, компилятор, поиск, IDE — тоже. ИИ встаёт в тот же ряд. Интересно другое: что вы делаете, когда инструмент ошибается.

Модель пишет быстрее, чем вы понимаете

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

Однажды что-то ломается, и вы стоите в кодовой базе, которая формально ваша, но объяснить её вы не можете даже себе. Раньше узким местом было то, как быстро я пишу код. Теперь — как быстро я его понимаю. Инструмент не замедляется, чтобы меня подождать.

Рабочий протокол

1. Читать дифф целиком, до того как принять. Не по диагонали.
2. Просить модель объяснить выбор и сверять объяснение с тем, что реально в коде.
3. Держать шаг маленьким, чтобы изменение умещалось в голове.
4. Проверять неразумные сценарии, а не только счастливый путь.
5. Отдельно спрашивать: что будет при повторном запуске и при падении.
6. Если не могу объяснить, почему это работает, — дальше код не идёт.

Ни один пункт тут не про печать символов. Все — про понимание.

Мой новый счёт

Аккаунту на GitHub больше десяти лет. Большую часть этого времени там было тихо: карьерные паузы, смены направления, жизнь как она есть. За последний год я создал и поддерживал больше проектов, чем за все предыдущие десять лет вместе.

Не буду делать вид, что портфолио написали инструменты. Кто-то всё равно решал, что строить, отлаживал, выпускал и держал это живым. Но старая метрика — «могу ли я произвести всё это из памяти, в одиночку, из пустого файла» — тихо мешала мне доводить дела до конца. Как только я перестал ею пользоваться, я начал строить.

Строки я больше не считаю. Вместо этого смотрю на то, что выпустил: понимаю ли я это, починю ли, когда отвалится, и готов ли под этим подписаться.