Компонент, API, починка бага, иногда целое приложение — всё это сегодня делается за часы там, где раньше уходили дни. Вместе с этим просел старый способ показывать свою ценность: «я знаю язык глубоко и могу написать вон ту сложную штуку руками». Написать может и модель.
Дальше — про то, что реально отличает разработчика, когда генерация кода стала обыденностью. Полезно и тем, кто пишет код, и тем, кто его принимает на ревью.
Что изменилось по сути
Раньше разработчик демонстрировал три вещи: знание языка, умение решать задачи и скорость. Проверялось это просто — достаточно было посмотреть на его код. Объём написанного, элегантность решения, редкий синтаксис: всё это работало как доказательство.
Генерация ломает эту проверку. Код перестаёт быть результатом и становится черновиком. А ценность смещается туда, где черновик нужно оценить, поправить и встроить в систему, которая будет жить годами.
Чем хвастались и чем хвастаются
| Что демонстрировали | Как это проверялось раньше | Что с этим сейчас |
|---|---|---|
| Объём кода | «Посмотри, сколько я написал» | Почти ничего не говорит: сгенерировать много — дело одной команды |
| Знание синтаксиса и библиотек | Вопросы на собеседовании, спор в курилке | Осталось полезным, но перестало быть витриной |
| Скорость | «Я сделал за вечер» | Скорость есть у всех, у кого есть доступ к модели |
| Умение разбить задачу на части | Замечали постфактум, по качеству архитектуры | Стало главным: модель делает ровно то, что вы сформулировали |
| Понимание предметной области | Считалось бонусом к технике | Часто важнее самой техники |
| Проверка чужого результата | Ревью как повинность | Отдельный навык, который видно сразу |
Навыки, которые остались в цене
Постановка задачи
Самое дорогое сейчас — уметь описать, что вообще нужно сделать. Не «сгенерируй форму», а какие поля, что с валидацией, что при пустом ответе сервера, куда полетят ошибки и что потом будет с этим кодом делать человек, который откроет его через полгода.
Тут есть неприятный момент: чтобы хорошо ставить задачу, нужно понимать, как это устроено внутри. Люди, которые «просто пишут промпты» и не читают результат, застревают на первом же нестандартном случае. Модель выдаёт правдоподобное решение, оно проходит быстрый тест — и разваливается на проде, потому что никто не проверил, откуда берутся данные.
Чтение и проверка кода
Сгенерированный код выглядит аккуратно. Он даже часто работает. Вопрос в том, что в нём спрятано: лишние запросы в цикле, тихо проглоченные исключения, предположения о формате данных, которые завтра изменятся. Умение за минуту увидеть такое — это то, за что платят.
Декомпозиция
Большую задачу надо разложить на куски, которые можно проверить по отдельности. Модель с этим не помогает: она охотно берётся за всё сразу и выдаёт монолит.
Вкус к продукту
Понимать, что именно делает штуку полезной, а что — просто аккуратной.
Отладка стыков
Самое болезненное — не код внутри файла, а место, где встречаются две системы с разными представлениями о мире.
Практика: когда генерацию брать, а когда нет
- Берите, когда задача типовая и результат легко проверить: обвязка, конвертеры, тесты, черновик миграции, разбор незнакомого формата.
- Берите, когда нужен второй взгляд на решение, которое вы уже придумали сами.
- Не берите то, что касается денег, доступов и удаления данных, если не готовы вычитать каждую строку.
- Не берите задачи, где вы не понимаете предметную область: проверить результат будет нечем.
Чек-лист перед тем, как принять сгенерированный код в проект:
- Могу ли я объяснить каждую строку вслух?
- Что произойдёт на пустых данных, на огромном объёме, при ошибке сети?
- Не появилось ли новых зависимостей — и кто их будет обновлять?
- Есть ли тест, который упадёт, если этот код сломают?
- Поймёт ли это коллега, который увидит файл впервые?
Типичные ошибки
Принимать код по признаку «запустилось». Отсутствие ошибки в консоли — не доказательство корректности.
Мерить себя объёмом. Отчёт «я закрыл сорок задач с помощью модели» ничего не говорит о вашей ценности, если половину потом переписывали.
Прятать использование модели. Скрывать, что задача решена с генерацией, — странно. Скрывать, что вы не проверили результат, — уже опасно.
Отказываться от глубины. Самый частый перекос: человек решает, что раз код пишет машина, то и разбираться в устройстве необязательно. Потом не может починить то, что сломалось.
И отдельно про собеседования: просьба «напиши функцию на доске» постепенно теряет смысл как фильтр. Куда показательнее — дать человеку сгенерированный кусок и попросить найти в нём проблему. Или обсудить, как он разложит задачу. Это видно за десять минут.
Вывод
Писать код руками — навык, который никуда не делся, но перестал быть витриной. Демонстрировать теперь можно другое: как вы формулируете задачу, как проверяете чужой результат, как раскладываете сложное на проверяемое. Это хуже продаётся одной строчкой в резюме, зато проверяется на реальной работе очень быстро — и в обе стороны.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.