Человеческий фактор, который все упускают
Когда Дарио Амодеи, генеральный директор Anthropic, сказал, что нас отделяет всего 6-12 месяцев от ИИ-систем, способных делать всё, что делают программисты, мне пришлось остановиться.
Это не "в будущем". Это практически следующий год.
В то же время Anthropic представила тесты производительности своей новой модели Claude Opus 4.5, показывающие значительные улучшения в кодировании, рассуждении и обработке сложных задач. Цифры выглядят действительно впечатляюще.
И я начал задаваться вопросом: действительно ли эти тесты означают, что разработка программного обеспечения вот-вот будет полностью автоматизирована? Позвольте мне разобрать, что, на мой взгляд, на самом деле происходит.
Что на самом деле тестируют эти бенчмарки
Согласно Anthropic, Claude Opus 4.5 справляется гораздо лучше предыдущих версий в тестах по разработке программного обеспечения, таких как SWE-bench, длинных задачах, требующих множества шагов, сложном рассуждении и эффективном использовании различных инструментов.
Вы также можете ознакомиться с блогом Anthropic для получения подробной информации.
Они также утверждают, что модель лучше сохраняет фокус во время расширенных рабочих процессов. Это действительно важно, потому что более ранние ИИ-модели были неплохи в написании отдельных фрагментов кода, но ужасны в запоминании контекста на протяжении нескольких шагов.
Если этот разрыв сокращается, потенциал для автоматизации определённо растёт.
Но вот что меня беспокоит. Бенчмарки вроде SWE-bench тестируют, может ли модель решать чётко определённые проблемы в контролируемых средах, обычно с обратной связью от тестов, которая её направляет.
Это совершенно отличается от беспорядочной реальности настоящей работы с программным обеспечением. Реальные проекты имеют расплывчатые бизнес-требования, которые меняются каждую неделю. Документацию, которая либо отсутствует, либо устарела. API от третьих сторон, которые ломаются без предупреждения. Пайплайны развёртывания, скреплённые скотчем. И заинтересованные стороны, которые все хотят разных вещей.
Бенчмарки измеряют технические навыки в вакууме. Они не измеряют вашу способность ориентироваться в организационном хаосе.
Что я вижу в реальной работе разработчиков
Я наблюдал, как люди на самом деле используют эти ИИ-инструменты для кодирования изо дня в день, и паттерн довольно ясен.
Да, ИИ теперь может генерировать полные рабочие программы. Я видел, как разработчики разворачивают полнофункциональные приложения за часы, на что раньше уходили дни. Но вот что они продолжают говорить: писать код никогда не было сложной частью.
Сложная часть - понять, что строить, иметь дело с меняющимися требованиями, управлять техническим долгом, поддерживать устаревшие системы и работать с людьми, у которых конфликтующие приоритеты.
Я также заметил специфические паттерны отказов. ИИ исправит баг A, что сломает функцию B. Затем исправит B, что снова сломает A. Этот цикл продолжается, пока кто-то вручную не вмешается. ИИ оптимизирует каждую часть изолированно, но не может видеть, как всё связано.
Другая вещь, с которой я постоянно сталкиваюсь, - это избыточное проектирование. ИИ-инструменты строят излишне сложные решения, потому что не ставят под сомнение первоначальный подход. Они просто реализуют то, о чём вы просите. Они не возражают и не говорят: "Подождите, это действительно лучший способ сделать это?"
Паттерн, который я вижу чаще всего: ИИ пишет код быстро. Люди всё ещё решают, какой код должен существовать.
Прирост продуктивности реален, но и ограничения тоже
Буду честен, ИИ уже обрабатывает тонну работы по реализации. Для стандартных CRUD-операций, каркасов и базовых интеграций рост продуктивности неоспорим. Я делаю больше быстрее в этих областях.
Но когда я работаю над сложными распределёнными системами, критичным для безопасности кодом или проблемами целостн��сти данных, моя уверенность в ИИ значительно падает.
Я недавно провёл неделю, отслеживая тонкое несоответствие контекста, которое вызвало каскадные отказы в нескольких сервисах. ИИ бы этого не поймал. В другой раз я понял, что объяснение моей всей системной архитектуры ИИ в достаточных деталях для генерации корректного кода займёт больше времени, чем просто написать его самому.
То, что происходит, - это не устранение работы. Это трансформация работы. Я перехожу от написания кода к проверке и редактированию кода. Это всё ещё требует глубокого понимания.
И вот что меня беспокоит: если мы заменим младших инженеров на ИИ, кто станет старшими инженерами через пять лет? Вы не можете научиться хорошо проверять код, если никогда сами не строили системы. Понимание приходит через действие.
Есть также вопрос подотчётности. ИИ может генерировать выходные данные, но не может владеть последствиями. Когда продакшен ломается в 3 часа ночи, кто-то всё ещё должен объяснить, что произошло, быстро исправить это и предотвратить повторение.
Инженерия - это не просто реализация. Это владение.
Почему эти прогнозы могут быть завышены
Давайте поговорим о бизнес-стороне на секунду.
ИИ-компании активно конкурируют за корпоративных клиентов и деньги инвесторов. Заявления о радикальной замене рабочих мест создают срочность. Они подталкивают компании быстро реструктурировать рабочие процессы вокруг ИИ-инструментов, прежде чем это сделают конкуренты.
Я думаю, агрессивные заявления об автоматизации могут также быть связаны с формированием рынка и ожидани��, даже если полная автоматизация не прибудет по расписанию.
Не поймите меня неправильно. Технология улучшается невероятно быстро. Но бизнес-стимулы вознаграждают оптимистичные сроки над реалистичными.
Часто существует большой разрыв между тем, куда движется технология, и тем, как быстро она фактически развёртывается в реальных компаниях с реальными ограничениями.
Что на самом деле готово к автоматизации (а что нет)
Основываясь на том, что я испытываю и наблюдаю, вот моя разбивка:
Готово к высокой автоматизации сейчас:
Код для общих паттернов
Каркасы тестов
Рефакторинг существующего кода
Документация
Внутренние инструменты
Возможно, на полпути:
Отладка с человеческим надзором
Многофайловые функции
Интеграции API, когда спецификации кристально ясны
Даже близко нет:
Решения о системной архитектуре
Переговоры по требованиям
Анализ компромиссов
Решения о надёжности продакшена
Моделирование безопасности
Долгосрочная стратегия обслуживания
Реализация становится драматически быстрее. Но принятие решений в условиях неопределённости никуда не исчезает.
Это объясняет то, что я вижу вокруг себя. Инженеры более продуктивны, но не менее важны.
Как использовать ИИ в разработке правильно — прямо сейчас
Вся эта дискуссия о том, что ИИ может и чего не может, поднимает важный практический вопрос: как разработчикам использовать эти инструменты эффективно уже сегодня?
Проблема не в том, что технология недостаточно развита. Проблема в том, что доступ к современным моделям часто затруднён - дорогие подписки, сложные API, ограничения по токенам.
Но ИИ для разработки уже стал облачным. Вам больше не нужна локальная установка или корпоративная подписка на GitHub Copilot за $20/месяц.
Сервисы вроде BotHub предоставляют доступ к тем же моделям Claude Opus 4.5, о которых мы говорим, прямо из браузера.
Для доступа не требуется VPN, можно использовать российскую карту.
По ссылке вы можете получить 300 000 бесплатных токенов для первых задач и приступить к работе с нейросетями прямо сейчас!
Настоящая работа никогда не была просто набором текста
Вот что я понял: самая сложная часть разработки программного обеспечения всегда была в решении, что строить и почему.
Код - это просто видимый результат этого решения. Инженерия - это невидимый процесс мышления, который его формирует.
ИИ становится действительно хорош в "как". Он нигде рядом с освоением "почему".
И вот ключевой момент: неправильные решения "почему" становятся дороже по мере роста систем. Более быстрая реализация означает, что ошибки также распространяются быстрее.
Иронично, но это может сделать сильное архитектурное суждение более ценным, а не менее.
Что на самом деле означает "автоматизация от начала до конца"
Позвольте разделить это на два сценария.
Если "от начала до конца" означает "ИИ может генерировать рабочий код, когда дана правильная, детальная спецификация", то да, мы довольно близки к этому уже сейчас.
Если "от начала до конца" означает "ИИ может выяснить правильные спецификации, разрешить конфликты между заинтересованными сторонами, управлять эволюционирующими требованиями и оставаться подотчётным за результаты системы", то нет, мы вообще близко не находимся.
Первое - это техническая проблема реализации. Второе - это организационная и когнитивная проблема.
Бенчмарки в основном измеряют первое.
Мой прогноз на следующий год
Вот что, я думаю, на самом деле произойдёт в течение следующих 12 месяцев:
Мы увидим меньше чисто реализационных младших ролей. Будет больше спроса на инженеров, которые могут чётко определять проблемы и принимать хорошие архитектурные решения. Агентные инструменты кодирования станут стандартом. Прототипирование и итерация станут намного быстрее.
Но мы также увидим продолжающуюся потребность в человеческом владении системами. Сильную зависимость от старших инженеров для проверки и принятия решений. И множество провалов, когда компании будут навязывать автоматизацию в плохо специфицированных областях.
Разработка программного обеспечения будет ощущаться совсем иначе через год. Но я не думаю, что сама роль исчезает.
Итоги
Бенчмарки Claude Opus 4.5 показывают реальный прогресс. ИИ-системы действительно становятся лучше в устойчивом рассуждении и структурированной генерации кода.
Но инженерия - это не просто производство кода. Это принятие решений в условиях неопределённости, ответственность за результаты и управление системами годами или десятилетиями.
Инструменты меняются быстро. Природа нашей работы смещается к более высоким уровням абстракции. Но сама роль не исчезает на годичном графике.
Я думаю, прогнозы полной автоматизации путают рост возможностей с фактической заменой в организациях.
И если история нас чему-то учит, эти две вещи редко движутся с одинаковой скоростью.
Что вы думаете? Действительно ли мы в 12 месяцах от того, чтобы ИИ заменил программистов, или это просто ещё один преувеличенный срок? Я бы хотел услышать вашу точку зрения в комментариях.
