Точка, в которой мы находимся
Линус Торвальдс вайб-кодит по выходным
100% кода, который разработчик контрибьютит в Claude Code написал Claude Code, а разработчик OpenAI говорит, что больше не пишет код (а мы ведь не считаем себя умнее их?)
Простые задачи Codex/Claude Code щелкают как семечки
Размер контекста растет по экспоненте, рано или поздно он должен был превзойти контекст среднего разработчика и по моему мнению это уже произошло с 99% программистов, оставшихся 1% превзойдет следующим (или максимум двумя) удвоениями
Но при это существует огромное количество проектов, где разработчики пробуют использовать Code-Assistant, матерятся и возвращаются с старому доброму написанию кода руками
Содержание статьи
Итак погнали и небольшой дисклеймер
Всё написанное ниже — моё субъективное мнение, основанное на личном опыте и текущем понимании происходящего.
Если я пишу «главное отличие», «очевидно», «единственное конкурентное преимущество» — это не абсолютная истина, а моя позиция на данный момент.
Я сознательно убираю из текста постоянные оговорки вроде «по моему мнению» и «как мне кажется», чтобы не перегружать стиль.
По умолчанию вся статья — это и есть моё мнение и приглашение к дискуссии.
Если вы видите картину иначе — тем интереснее обсудить.
Где Claude Code и Codex работают хорошо
Краткий ответ: там где им хватает контекста.
Особенно хорошо, там где есть система и хорошая архитектура.
Добавить API-ручку
Добавить валидацию
Добавить фильтр и пару scope в админке
Сделать сервис, который что-то фильтрует и в любом API-формате отдает результат
Написать тест
Выписать список всех routes, которые использует frontend-client
Удалить неиспользуемый код из модели
Сделать генератор сущностей, нагенерить тестовых данных
Все это становится простой и посильной задачкой для последних версий Codex/Claude Code
Ну а синтаксис языков, API фреймворков, использование библиотек, пакетов, гемов - последние LLM знают лучше любого разраба.
Но всё это работает только если хватает контекста
Но есть проекты, где всё иначе
Даёшь AI-агенту задачку и он творит какую-то дичь, ломает где-то в другом месте, пишет какой-то код, которые не понимает контекст и проще написать самому, чем заставить агента сделать задачку
В каких случая такое происходит? Вот несколько причин, которые я насобирал
У данных нет единого хозяина (сервиса, микросервиса, репозитория) и они могут менять из разных мест совершенно по-разному
В проекте нет валидаций или есть только валидации изменений, но нет валидаций состояний (в итоге в БД может быть что угодно)
Когда одна и та же сущность созданная в разное время может иметь разную схему (привет любителям MongoDB)
Когда данные хранятся вне реляционной модели, и вообще никто не может гарантировать связанность данных
Вообще нет тестов
Одни и те же сервисы используются и для изменения/создания данных и для отображения результата
В итоге даешь задачку - получаешь баг. Что-то постоянно не работает, появляется раздражение.
В целом тут как с людьми: если хорошая архитектура - задачи щелкаются, если плохая - любое изменение баги и мучения.
И AI-агенты в этом случае увы просто ускоритель процесса деградации системы. А бардак данных - самое сложно исправимое.
Как же подготовить проект к эпохе агентов?
Подготовить проект для ИИ - это не значит сменить стек, не значит переписать всё на Rust, не значит внедрить новый фреймворк и не дай бог "провести рефакторинг"
На мой взгляд это значит привести в порядок структуру хранения данных, обложить всё тестами, правилами, валидаторами и документацией.
И сделать это сейчас - в разы проще чем 5-7 лет назад.
Первое и самое важное, на что нужно обратить внимание - это структура данных. Это ядро системы, структура должна быть понятна не только backend-разработчику, но и frontend-разработчикам, всем кто проектируем интерфейсы, продакт-менеджеру, дизайнеру, владельцу продукта (в общих чертах)
Должно быть очевидно:
где какие хранятся данные, кто источник правды, а где репликация и кеш
кто "хозяин" данных (какой сервис, микросервис, модель в MVC)
где проходят валидации, где лежит бизнес-логика изменения этих данных
какие есть связи
какие есть допущения, ограничения, и как они проверяются
Когда это гарантировано - код упрощается в разы.
На моём опыте - одна валидация может убрать из кода до десятка разных if/else, try/catch, etc
После приведения данных в порядок очень помогают описанные правила "как мы пишем код"
как вызываются сервисы
в workers только вызов сервисов или может быть бизнес-логика
обязательный формат ответа любого сервиса
что обязательно покрывать тестами
структура любой модели: константы, связи, scope, валидации
версионирование
именования от routes до таблиц в БД
etc
И что прекрасно:
Во-первых агенты умеют соблюдать эти инструкции лучше чем люди
Во-вторых приведение сейчас кодовой базы в порядок - стало в десятки раз более простой задачей
Тут очень хорош и много можно поучиться у создателей Rails - Convention over Configuration (когда жестко заданы структура проекта, именования моделей, именования таблиц в БД, связка роутинга и названий контролеров и т.д. и т.п.)
И когда проект приведен в порядок - написать API-ручку становится минутной задачей, ��адачи легко дробятся на куски, помещаются в контекст, покрываются тестами, и агенты начинают работать. И отлично справляться и с проблемами кеша, N+1, оптимизации запроса в БД и т.д.
Ценность написания кода снижается, ценность архитектуры и описанных правил остается и становится конкурентным преимуществом.
Как эффективно писать код с помощью агентов?
Главное правило: "Дроби задачу до тех пор, пока она не помещается в контекст"
Это правило в целом касается и людей, но с ИИ особенно критично.
Рабочий процесс
Пишем план до тех пор, пока самим не станет понятно, из чего состоит задача.
Декомпозируем каждый пункт: route, контроллер, сервис, воркер, асинхронность.
Формируем чек-лист.
Мой чек-лист опросник при постановке задачи:
какие ручки затрагивает (route/controller)
какие сервисы менять/написать
меняется ли структура данных
появляются ли новые сущности, добавляются ли поля
если есть schema migration, нужно ли делать data migration
речь про получение данных или создание/изменение
нужны ли валидации
есть ли новые библиотеки
есть ли отложенные задачи
нужны ли проверки прав доступов
какие тест кейсы надо описать, какие крайние случаи проверить
Если на все вопросы есть ответы - код пишется мгновенно.
Что делать, если ты разработчик
Если у вас уже всё неплохо
То есть уже есть тесты, порядок в структуре данных, Swagger, документация - то расширяй личный контекст.
Например, если ты backend - бери немного frontend, аналитики, data scientist, ETL систем и т.д.
Обязательно пробуй более сложные задачи для агента, раз в месяц проверяй границу его возможностей. Давай большую задачу, не справился - дроби. Через месяц снова пробуй снова задачу такого же масштаба.
Если у вас в проекте бардак
То ИИ для тебя - это способ обрести контроль.
Нет тестов — начинай писать тесты. Это занимает минуты. Запускай их сам. Настрой CI
Приведи в порядок валидации состояний, приведи структуру файлов к единого вида, напиши для начала Unit-тесты (на связи, на валидации, на валидные фабрики и т.д.)
Удаляй лишнее каждый день:
неиспользуемый код
лишние колонки
старые сущности
неиспользуемые роуты
Раньше такие задачки требовали много мыслетоплива, сейчас же такой мелкий рефакторинг не требует его вообще.
И помни: ценность написания кода - падает, ценность архитектуры и системы код + данные - нет.
Что делать если ты Lead
Каждый разработчик должен стать кратно более продуктивным.
Ценность написания кода снижается.
Код + данные + команда + скорость роста - устойчивое преимущество.
Твой актив: команда + код + данные + инструментарий, которые дают скорость без деградации.
Вводи дисциплину:
ежедневная работа с тестами
ежедневная работа с чистотой кода
единая структура
чек-листы
Обучай продуктов, проджектов и дизайнеров структуре данных.
Коммуникация начинает играть критическую роль.
Если команда не научится работать в этом темпе - её обгонят.
Если компания маленькая - конкуренты, если большая - соседние команды.
Раньше написанный за 10 лет код и его знание - были действительно конкурентным преимуществом, сейчас уже нет.
Что делать владельцу продукта
Вопрос не в том, используете ли вы AI. Вопрос в том, выдержит ли система ускорение.
AI - ускоритель. Он не создает порядок, он ускоряет процессы (как плохие так и хорошие).
Инвестиции в архитектуру, команду, структуру - это актив.
Тесты, CI, документация - инструмент масштабирования.
Найм меняется. Нужны те, кто понимает систему и готовы подстраиваться под темп.
Темп становится конкурентным фактором.
Как я думаю куда мы идём
Контекст растёт по экспоненте.
Для 99% программистов он уже больше человеческого.
Писать код вручную перестаёт быть главным навыком.
Как большинство разработчиков перестали думать о памяти и управлении буферами, так же большинство перестанут думать о написании метода или сервиса.
Думаю, часть профессии станет операционной.
Наука → ремесло → специальность.
Большая часть станет операторами.
Меньшая часть останется архитекторами смыслов.
Финал
ИИ не заменяет программиста.
Писать код стало просто.
Строить систему по-прежнему сложно.
Если вы умеете держать структуру данных в порядке и управлять контекстом - вы усиливаетесь.
Если нет - ускоряете деградацию.
Это не конец профессии. Это её взросление.
