Слогер Создать блог
Разработка

Что делать, если ИИ пишет код: как меняется роль разработчика

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

На мини-конференции по AI и Software Engineering в Zone01 Kisumu панельная дискуссия незаметно превратилась в разговор, который большинство разработчиков ведут у себя в голове. Панель, а следом и кейноут Amariah Abishai, основателя Atlarix, сходились к одному: если модель пишет код быстрее вас, за что вам платят?

Единого ответа не было. Зал спрашивал про доверие к коду, написанному не тобой, про то, чему учить новичков, и про то, становимся ли мы лучшими инженерами или просто лучшими в промптах. Но одна мысль звучала из разных реплик одинаково: основы никуда не делись, поменялся рабочий процесс.

Каменщик становится архитектором

«Никто не рассылал служебную записку, но работа тихо изменилась».

Раньше разработчик был каменщиком: клал кирпичи, и именно за это получал деньги. Модели научились класть многие из этих кирпичей — быстро, ровно и без перекуров.

Что остаётся на человека:

  1. Понять, что вообще строить. Это правильная задача? Достаточно ли в ней пользы, чтобы тратить месяцы? Модель тут не выручит: она охотно сгенерирует решение для проблемы, которой у пользователей нет.
  2. Решить, чего не строить. Держать объём под контролем — отдельная работа.
  3. Продумать структуру. Как части системы соединяются, где проходят границы, что случится, когда нагрузка вырастет в десять раз.
  4. Заметить, когда всё пошло не так. Самый недооценённый навык. Код от модели выглядит разумно, компилируется, проходит сгенерированные тесты — и всё равно может содержать серьёзную ошибку.

Машина помогает класть кирпичи. Чертёж остаётся за вами.

Чему учить джуна, если код пишет модель

На этом вопросе панелисты споткнулись сильнее всего. Соблазн понятный: модель выдаёт работающий код, зачем мучиться с основами?

Схема, к которой легко скатиться — ИИ пишет → я вставляю → я иду дальше. Через пару месяцев такой работы приходит задача, из которой промптом не выкрутиться: падает прод, а вы не понимаете, что происходит внутри.

Рабочая схема другая: я думаю → ИИ помогает → я понимаю → я проверяю → я улучшаю. Разница сидит в двух шагах посередине, и они самые неудобные.

Чем быстрее модели генерируют код, тем важнее читать их результат достаточно внимательно, чтобы задавать неудобные вопросы. Ценность теперь не в том, сколько строк ты выдал, а в том, какие решения принял.

Проверять, а не доверять

Главный вывод сессии простой: код от ИИ всё ещё требует инженерного суждения. Тесты, ревью, понимание архитектуры никуда не делись — просто раньше их можно было откладывать, потому что код писал человек и худо-бедно держал его в голове.

Как устроить проверку на практике:

  1. Прочитайте код целиком до запуска. Не тестируйте то, чего не поняли. Если не можете объяснить строчку своими словами — не пропускайте её.
  2. Проверьте края. Пустой ввод, ноль, отрицательное число, гигантский список, отсутствие прав, параллельный доступ. Граничные случаи модели продумывают редко.
  3. Напишите свои тесты. Сгенерированные тесты проверяют то, что модель считает правильным поведением. Ваши — то, что нужно вам.
  4. Ищите правдоподобие. Основной риск — не откровенная чушь, а код, который выглядит правильным, но делает не то. Сравнивайте его с формулировкой задачи, а не с тем, насколько аккуратно он смотрится.
  5. Спросите модель, чего она не учла. Прямой вопрос «какие допущения ты сделал и что здесь может сломаться» иногда даёт больше, чем ревью коллеги.

Когда подход работает, а когда нет

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

Что изменилось на самом деле

ВопросДо моделейСейчас
Источник ценностиСкорость и объём написанного кодаВыбор задачи и структура системы
РутинаТиповые функции и обвязку писали рукамиОтдаём модели, проверяем выборочно и внимательно
Узкое местоКак быстро ты печатаешьКак точно ты ставишь задачу и проверяешь результат
Типичная ошибкаНе тестировал свой кодДоверился коду, который выглядит правильным
Что учить в первую очередьСинтаксис, библиотеки, APIАрхитектура, тестирование, чтение чужого кода

Где мы в итоге оказались

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

Титул архитектора никто официально не выдавал. Просто инструменты поменялись, и роль поменялась вместе с ними. Кирпичи теперь дешёвые. Дорогие — чертежи.

По материалам: career. Текст переработан редакцией Слогера.

← На главную

Рекламное место — Конец поста
Реклама · Слогер

Комментарии (0)

Войдите, чтобы комментировать.

Пока нет комментариев. Будьте первым.