Команда AI for Devs подготовила перевод статьи о том, как меняется программирование с приходом ИИ. Автор делится опытом: в его проекте уже 90% кода пишется агентами, но вся ответственность за архитектуру и продакшен остаётся на нём. По мнению автора, это не далёкий прогноз — это уже реальность, просто распределённая неравномерно.

«Я думаю, что через три-шесть месяцев мы придём к тому, что ИИ будет писать 90% кода. А ещё через год — к миру, где ИИ пишет фактически весь код».

— Дарио Амодеи

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

В инфраструктурном компоненте, который я начал в своей новой компании, доля кода, написанного ИИ, уже перевалила за 90%. Я не хочу никого убеждать — просто поделюсь тем, что узнал. В том числе потому, что к этому проекту я подошёл иначе, чем к своим первым экспериментам с программированием при помощи ИИ.

Сервис написан на Go, с минимальным количеством зависимостей и REST API, совместимым с OpenAPI. В основе — отправка и приём писем. Я также сгенерировал SDK для Python и TypeScript с помощью собственного генератора. В сумме получилось около 40 000 строк: Go, YAML, Pulumi и немного "клея" для SDK.

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

Контекст

Некоторые стартапы уже близки к 100% кода, сгенерированного ИИ. Я знаю это, потому что многие разрабатывают открыто, и их код можно увидеть. Сработает ли это в долгосрочной перспективе — пока вопрос. Для себя я по-прежнему считаю каждую строку своей ответственностью, как будто написал её сам. ИИ этого не меняет.

В проекте нет странных файлов, которые там не должны быть, нет дублированных реализаций, и репозиторий не усыпан эмодзи. Комментарии выдержаны в нужном стиле и, что особенно важно, часто вообще отсутствуют. Я уделяю большое внимание базовым вещам: архитектуре системы, организации кода, взаимодействию с базой данных. У меня очень чёткие принципы. Поэтому есть вещи, которые я не позволяю ИИ делать. Я знаю, что он никогда не дойдёт до того уровня, чтобы я мог подписать коммит «вслепую». Поэтому это и не 100%.

Для контраста: другой быстрый прототип, который мы собрали, превратился в бардак из неясных таблиц в базе данных, захламлённых markdown-файлов и кучи ненужных эмодзи. Он выполнил свою задачу — проверить идею, но не был рассчитан на долгую жизнь, и мы этого от него и не ожидали.

Фундамент

Я начал по-старому: дизайн системы, схема, архитектура. На этом этапе я не даю ИИ писать код, но использую его как «резиновую уточку» — проговариваю идеи, задаю вопросы. Такой диалог помогает заметить ошибки, даже если я не нуждаюсь в ответах или не доверяю им полностью.

Один раз я всё же ошибся в фундаменте. Сначала я убедил сам себя в более сложной схеме, чем хотел. Позже именно тут я использовал LLM, чтобы переписать большую часть системы на раннем этапе и всё упростить.

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

• Чистый SQL. Это, пожалуй, самое большое отличие от того, как я писал раньше. Мне нравится работать с ORM, но не нравятся его побочные эффекты. В частности, как только ты упираешься в пределы ORM, приходится переключаться на ручной SQL. Эта трансляция утомительна: часть возможностей ORM теряется. Ещё одна проблема — крайне сложно понять, какие реальные запросы выполняются, что усложняет отладку. Видеть в коде и в логах базы именно тот SQL, который выполняется, — это очень ценно. ORM всегда это скрывает.
  Факт, что мне больше не нужно писать SQL самому, потому что это делает ИИ, — переломный момент.
  Теперь я использую чистый SQL и для миграций.

• OpenAPI-first. Я перепробовал разные подходы и фреймворки. В итоге остановился на том, чтобы сначала сгенерировать OpenAPI-спецификацию, а затем — код для интерфейсного слоя на её основе. Этот подход лучше работает с кодом, созданным ИИ. OpenAPI-спецификация теперь — каноничный источник, на который опираются и клиенты, и серверные заглушки.

Итерации

Сегодня я использую Claude Code и Codex. У каждого свои сильные стороны, но неизменным остаётся одно: Codex — это инструмент для code review после PR, и делает он это отлично. Claude незаменим при отладке и тогда, когда нужен доступ к инструментам (например, почему возник deadlock, откуда в базе повреждённые данные и т. д.). Но настоящая магия — в их связке: Claude может найти данные, а Codex — лучше их интерпретировать.

Я не устану повторять: код этих агентов может быть ужасным, если не быть внимательным. Они понимают архитектуру и то, как собрать систему, но не могут удерживать в фокусе всю картину. Они создают заново то, что уже есть. Они строят абстракции, совершенно не подходящие для масштаба задачи.

Нужно постоянно учиться правильно формировать контекст. Для меня это означает указывать ИИ на существующие реализации и давать максимально конкретные инструкции, как действовать.

Обычно я создаю изменения размером с PR, чтобы можно было их нормально просмотреть. Есть два пути:

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

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

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

Где всё ломается

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

Очень легко построить систему, которая внешне вроде бы работает правильно, но при этом её поведение в рантайме остаётся неясным, если слишком полагаться на агентов. Например, ИИ до конца не понимает многопоточность или goroutines. Если не остановить неверные решения на раннем этапе, позже система не будет работать стабильно.

Вот пример: я попросил его сделать rate limiter. Он «заработал», но там не было джиттера и использовались плохие решения для хранения состояния. Исправить это несложно, если ты понимаешь, как устроены rate limiters, но это становится опасно, если знаний не хватает.

Кроме того, агенты действуют на основе «коллективной мудрости» из интернета и из-за этого делают то, чего я сам никогда бы не сделал. Им нравится тянуть зависимости (особенно устаревшие). Им нравится проглатывать ошибки и убирать все traceback’и. Я же предпочитаю поддерживать жёсткие инварианты и пусть код падает с шумом, если они нарушены, а не скрывать проблему. Если этого не пресекать, в итоге получаются непрозрачные, необозримые системы.

Где это работает лучше всего

Для меня всё дошло до того, что я уже не могу представить работу по-другому. Да, я, вероятно, смог бы сделать это и без ИИ. Но тогда система во многом получилась бы иной, потому что я принял бы другие компромиссы. Такой способ работы открывает пути, которые раньше я бы пропустил или отложил «на потом».

Вот несколько вещей, которые особенно понравились в этом проекте:

• Исследования + код сразу, а не исследования, а потом код: то, на что раньше уходил день или два, теперь занимает 10–15 минут. Я могу сразу поиграть с одной-двумя реализациями задачи. Это переводит меня из абстрактных размышлений в режим практической проверки.

• Эксперименты: за один день я попробовал три разных реализации и подхода к OpenAPI.

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

• Инфраструктура: Claude провёл меня через AWS и Pulumi. То, что я обычно не люблю и что заняло бы недели, сократилось до пары дней. Он же по ходу отлаживал проблемы с конфигурацией. Мне почти не пришлось читать документацию.

• Освоение новых практик: хоть они и плохо пишут тесты, агенты отлично справляются с подготовкой тестовой инфраструктуры, о которой я бы и не подумал. В Twitter мне посоветовали использовать testcontainers для тестов с Postgres: миграции выполняются один раз, а затем для каждого теста создаются клоны базы. Это оказалось невероятно удобно. Раньше переход на такой подход был бы отдельным сложным проектом, а Claude сделал всё за час для всех тестов.

• Качество SQL: он пишет отличный SQL, который я сам никогда бы не вспомнил. Я просто просматриваю результат — это я умею. Но до сих пор я ужасно запоминаю MERGE и WITH, когда пишу их вручную.

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

Будет ли 90% кода писаться ИИ? Я не знаю. Но точно знаю одно: для меня, в этом проекте, ответ уже «да». Я отношусь к той растущей группе разработчиков, которые создают реальные системы именно так.

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

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

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

Русскоязычное сообщество про AI в разработке

Друзья! Эту новость подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!