GitHub: ИИ переписывает карьерную лестницу разработчика — решают не строки кода, а суждение

Что меняется в работе разработчика

По формулировке GitHub, меняется само исполнение работы: «хорошее исполнение» всё чаще означает чётко определить проблему, дать нужный контекст, оценить сгенерированный код и решить, что готово к отправке.

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

Конкретный пример GitHub — задача добавить новый поток аутентификации. В привычном виде она выглядела как цепочка шагов одного разработчика: создать ветку, написать код, прогнать тесты, открыть pull request. Теперь тот же результат всё чаще собирается в рабочем пространстве, где один агент помечает аутентификацию готовой к ревью, второй — черновик документации, третий — набор тестов.

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

Навык 1: направлять ИИ, а не просто им пользоваться

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

По мере того как агенты берут на себя всё больше реализации, эти навыки становятся не менее, а более ценными.

Вывод GitHub для первого навыка сформулирован прямо — «научиться направлять агентов», а не просто «пользоваться ИИ».

Навык 2: не доверять первому ответу модели

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

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

GitHub предлагает конкретный приём: попросить вторую модель раскритиковать работу первой, а затем самому сравнить оба ответа.

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

Разные модели, по формулировке GitHub, сильны в разном и слепы в разном — поэтому второе мнение часто ловит то, что пропустила первая модель.

На этой идее построен встроенный в GitHub Copilot агент Rubber Duck: он использует вторую модель, чтобы проверять планы, код и тесты до того, как разработчик двинется дальше.

Короткий вывод совета: ИИ стоит доверять настолько, чтобы им пользоваться, но не настолько, чтобы пропускать проверку.

Навык 3: решать задачи крупнее

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

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

На примере задачи «добавить тёмную тему» GitHub разводит работу ИИ (реализация, тесты, документация) и чек-лист разработчика: подтвердить проблему клиента, разобрать архитектурные компромиссы, проверить доступность, определить метрики успеха и утвердить решение.

Вывод совета: пусть ИИ берёт на себя больше реализации, чтобы у команды оставалось больше времени на суждение.

Что это значит

Вывод GitHub прост: навыки, с которых начинается карьера, меняются, и выигрывают те, кто учится работать с ИИ, не отказываясь от суждения, которое ИИ не заменяет.

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

Это редакционная колонка GitHub о требованиях к разработчикам, а не анонс продукта: конкретных метрик, сроков или обязательств по продуктам в материале нет — только практические советы и внутренние примеры. Материал занимает около трёх минут чтения.