6 месяцев работы с Claude и Cursor, часть 3: Когда машина начинает учиться самостоятельно

Навык превратился в артефакт, который конвейер создает, архивирует и использует самостоятельно. Это автоматизация с контролем в нужных точках.

Изображение создано с помощью Gemini

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

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

Август: месяц объемов

Source Genesys (SG) — это технология для создания вертикальных SaaS-платформ. Она полностью автоматизирована с помощью Cursor, и у нас уже есть несколько платформ в производстве. У SG есть CLI-команда, которая автоматизирует процесс программирования с помощью пользовательского CI/CD конвейера. Август был временем для тестирования и разработки навыков для Cursor и Claude.AI. Было много документации для анализа качества и безопасности кода.

Августовский отчет зафиксировал 507 выполнений за 833 сессии с уровнем успеха 85,4%. Это 10 активных платформ, 10 генераторов, работающих параллельно. Все данные получены из моих собственных рабочих сессий.

Число, которое важнее всего — это не общее количество. Важно распределение. AAA (основной контроллер системы арендаторов) лидировал по публикациям с 47, за ним следовал MDS с 39. Вместе эти две платформы составили более половины общего объема за месяц. Это не случайность; это отражает то, где была сосредоточена разработка.

Пик активности приходится на 14:00, с 72 выполнениями. Но реальное поведение проявляется, если посмотреть на полную кривую: значительная активность наблюдается в 22:00, полночь и 1:00 ночи. Работа не останавливается, когда заканчивается день. Конвейер доступен до тех пор, пока вы не спите, и это меняет то, как вы распределяете свое внимание в течение дня.

Как активность распределяется в течение дня

На графике ниже показано количество выполнений автоматизированных команд SG CLI по часам в августе. Пик в 14:00 (72 выполнения) соседствует с постоянной активностью в ночное время, что дает понять: конвейер работает как продолжение рабочего ритма, а не как замена рабочим часам.

Ежедневная активность по часам

Цена объема: сбои и то, что они показывают

Большой объем влечет за собой сбои. За месяц 74 выполнения закончились ошибкой. Общий показатель составил 85,4%, что технически находится в пределах нормы, но важно ежедневное изменение, а не среднее значение. График ежедневного успеха колеблется от 100% до 25% в течение месяца, с идеальными пиками, за которыми следуют тяжелые дни. Это не постепенная деградация. Эпизодическую нестабильность диагностировать сложнее, чем устойчивый спад.

Тепловая карта сбоев по платформам и командам четко показывает закономерность. Для ActivateObservability, команды для самостоятельной публикации наблюдаемости в Grafana Cloud без участия человека, MDS удерживает наибольшее абсолютное число сбоев: 12 случаев. Это потому, что это базовая система и шаблон для всех остальных платформ. Число возникло не из-за сложной платформы; оно возникло из-за команды с непоследовательным поведением. Сбой произошел во время активации, а не в самой платформе. Когда одна и та же команда дает сбой в [PIX]BOL, CRMW, AAA и Entity, гипотеза об изолированной проблеме становится несостоятельной.

ActivateObservability закончила август с уровнем сбоев 48,6%. TestAPI показал 66,7%. Вместе эти две цифры указывают на то, где конвейеру еще предстоит поработать: активация наблюдаемости и тестирование API, которые настраиваются для каждой платформы, являются наиболее критическими точками в системе.

Уровень сбоев по платформам: где конвейеру еще предстоит поработать

На графике ниже показан уровень сбоев моего проекта по платформам в августе. MDS лидирует с 25,7%, это самое высокое значение в экосистеме, и это базовый шаблон, который питает все остальные платформы.

Сбои (%) по платформам

Уровень сбоев MDS в 25,7% требует внимания по двум причинам. Первая — это объем: 39 публикаций в месяц означают, что каждый сбой имеет цену в реальном времени. Вторая — это шаблонная природа платформы MDS. Проблемы здесь могут распространяться на каждую сгенерированную платформу.

Но цифра не показывает всей картины. MDS — это также платформа, где разработка наиболее интенсивна, где новые паттерны тестируются первыми и где конвейер получает наиболее значительные изменения до того, как они будут распространены. Высокий уровень сбоев на платформе, находящейся в активной разработке, — это не то же самое, что на стабильной платформе.

Какие навыки изменились в конвейере

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

Первое направление — масштаб. С более чем 500 активными навыками, охватывающими все: от идентификации системы до шаблонов паролей, CI/CD, наблюдаемости и поведения Cursor, объем контекста, доступного для сессии, вырос. Это напрямую влияет на качество генерируемых промптов: когда ИИ знает канонический паттерн, предписывающий промпт становится короче. Меньше места для импровизации Cursor.

Второе направление было неожиданным.

Автоисправление: когда конвейер учится писать свои собственные навыки

15 августа лог конвейера показал нечто иное в AutoFix, модуле ИИ, использующем Cursor и несколько навыков. AutoFix запустился, исправил ошибку TypeScript в AAA и автоматически сгенерировал навык 31-sg-ts2307-module-not-found.mdc. Никакого ручного вмешательства. Никакого дополнительного промпта.

Название, которое получилось в итоге, было SG AUTO FIX.

Механизм работал так: когда AutoFix устранял ошибку без предварительной записи, он генерировал навык с шаблоном проблемы, контекстом затронутой платформы и примененным решением. Навык сохранялся с TTL 15 дней, порядковым номером и автоматически становился доступным для будущих сессий.

Затем конвейер приобрел отличие, которое на практике является самым важным из всех: перед применением любого исправления AutoFix должен был классифицировать файл с ошибкой. Если файл был сгенерирован SG и имел соответствующий шаблон, сопоставленный в коде SG, исправление должно было попасть в шаблон, а не в сгенерированный файл. Исправление вывода без исправления источника означало бы, что при следующем запуске генератора ошибка вернется.

Это изменило природу AutoFix, превратив его из средства устранения последствий в средство исправления на уровне источника.

Чтобы убедиться, что ни одно исправление шаблона не прошло без проверки, SG AUTO FIX был настроен на отправку уведомления каждый раз, когда он изменял шаблон SG, с полным diff того, что было и что стало. Петля обучения получила обязательную точку человеческого контроля именно в том месте, где риск наиболее высок.

Что большой объем показал о конвейере

С консолидацией больших объемов данных за август динамика изменилась: Cursor генерировал свои собственные инструкции по исправлению, а Claude стал вторым мнением, тем, которое я проверял перед тем, как одобрить то, что конвейер решил самостоятельно.

PublishDirect (CI/CD, полностью автоматизирующая публикацию артефактов) накопила 924 минуты за месяц, что составляет более 15 часов времени сборки — более чем в 10 раз больше, чем следующая по затратам ресурсов команда. Она потребляет больше всего времени, потому что выполняет больше всего работы. Смысл не в том, чтобы сократить это число, а в том, чтобы понять, что за ним стоит: каждая минута успешной работы PublishDirect — это платформа, работающая без ручного вмешательства.

Среднее время сборки на платформу варьируется от 0,37 минуты для ADV до 4,2 минуты для CRMR. Этот 11-кратный разброс между крайними значениями не обязательно является проблемой; более сложные платформы собираются дольше. Важен показатель P90: у CRMR и MDS самые высокие значения P90 в экосистеме, что означает, что значительная часть сборок на этих платформах происходит гораздо медленнее медианного значения. Когда P90 значительно выше P50, конвейер нестабилен, а не медленен.

Скажем так: если P50 = 8 мин, а P90 = 22 мин, разрыв составляет 14 минут.

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

Медленный конвейер имел бы высокие показатели и P50, и P90.

Нестабильный конвейер имеет P90, значительно превышающий P50; в данном случае это CRMR и MDS.

График потребления минут сборки в день показывает, что 31 июля было затрачено почти 160 минут, после чего последовал резкий спад. Сопоставление с объемом сессий показывает, что это был день с самой высокой активностью за весь период. Было проведено три раунда полной пересборки на нескольких платформах подряд для исследования и устранения ошибок в шаблонах. Каждый раунд создавал блок логов, которые ИИ автоматически анализировал, генерировал целевой промпт и применял исправление, при этом ручная интерактивная работа велась параллельно с Cursor в каждом отдельном случае.

Что остается человеческой работой

При наличии автоматизированного конвейера, активной наблюдаемости, навыков генерации AutoFix и уведомлений о шаблонах возникает очевидный вопрос: что все еще требует участия человека?

Честный ответ: больше, чем кажется, и именно в самых важных точках.

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

Исправления шаблонов требуют проверки. Когда SG AUTO FIX изменяет файл шаблона, отправляется уведомление с полным diff. Принятие этого изменения без проверки означало бы делегирование агенту решения, которое влияет на каждую сгенерированную платформу.

Заключение

Когда я писал Часть 1, навыком был контекст. В Части 2 — калибровка позиции. В августе им стал артефакт, который конвейер генерирует, архивирует и анализирует самостоятельно.

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

Число, которое подводит итог августа, — 85,4% успеха при 507 выполнениях. Но то, что представляет собой это число, отличается от того, что оно значило бы полгода назад. В январе 85% успеха означали бы выполнение 85% небольшой задачи.

В августе это означает, что 85% из 10 платформ работают без ручного развертывания и настройки наблюдаемости, и впервые появился конвейер, который умеет документировать свои собственные исправления.

Автоматизируйте с помощью ИИ. Но не переставайте проверять то, что действительно важно. Эта часть по-прежнему ваша работа.

Автоматизируйте с помощью ИИ. Но не переставайте проверять то, что действительно важно. Эта часть по-прежнему ваша работа.