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