ИИ может быстро предложить правку. Ответственность за то, что она сохраняет смысл продукта, остаётся у инженера. Поэтому полезный вопрос звучит не «напишет ли ИИ код?», а какую ограниченную задачу дать, какой контекст разрешить и как проверить изменение?
Выберите задачу, у которой есть критерий готовности
Хороший первый запрос: «Функция считает сумму заказа дважды для позиции с количеством больше одного. Найди причину в разрешённом проекте, предложи минимальное исправление и тест для одной и нескольких единиц. Покажи diff, не применяй решение без моего ревью».
Плохой запрос: «Оптимизируй весь сервис». В нём нет границ файлов, ожидаемого поведения и условий проверки. Даже убедительный ответ может заменить бизнес-правило другим.
Что передать в контекст
Укажите язык и версии библиотек, затронутые файлы, ожидаемое поведение, контракт API, схему данных или тестовые примеры, если они нужны. Приложите только разрешённый материал. Не вставляйте токены, пароли и реальные персональные данные в описание задачи. Если логи содержат чувствительные сведения, подготовьте безопасный фрагмент.
Контекст важнее красивого промпта. Без схемы таблицы ИИ может придумать колонку; без версии SDK — вызвать несуществующий метод; без бизнес-правила — «исправить» код так, что тест пройдёт, а расчёт станет неверным.
Пример: маленькое исправление в TypeScript
Предположим, исходная функция ошибочно прибавляет цену ещё раз:
function lineTotal(price: number, quantity: number): number {
return price * quantity + price;
}
Ожидаемое правило: цена одной единицы умножается на количество. Предложение ИИ может выглядеть так:
function lineTotal(price: number, quantity: number): number {
return price * quantity;
}
Но прежде чем принять diff, инженер задаст вопросы: допустимо ли нулевое количество, как округляются деньги, может ли цена быть отрицательной, где применяется скидка, покрывает ли тест реальное правило заказа? Успешный тест на одном примере не отвечает на всё это.
Рабочий цикл короткий: разрешённый проект → конкретная задача → план → diff → проверки → инженерное ревью → решение о применении. Если меняется SQL, добавьте EXPLAIN на тестовой среде, проверьте индексы и объём результата; синтаксически верный запрос может быть дорогим или раскрывать лишние строки.
Где помощь особенно полезна
В рамках доступного контекста ИИ может объяснять незнакомый модуль, формулировать гипотезу ошибки, предлагать небольшой рефакторинг, набросать тест и документацию, помочь разобрать API или SQL. Эти варианты — типы задач, не обещание, что агент автоматически выполнит каждый из них в любом репозитории. Границы зависят от разрешённого проекта, среды, модели и плана.
Проверяйте отдельно: выдуманные API, неверную бизнес-логику, безопасность, лишние зависимости, совместимость версий, крайние случаи и тесты, которые закрепляют ошибку. Нужен инженер, который может отклонить предложение и объяснить почему.
Что именно предлагает yCode
yCode — Beta-инструмент Yasnora для задач разработки: работа с разрешённым проектом, план, изменения в виде diff и результаты проверок перед решением человека. Для запуска нужны аккаунт, доступ к проекту и настроенная среда. Публичная страница продукта описывает задачи чтения на Free; изменения и тесты относятся к платному доступу. Проверяйте доступность в своём аккаунте. Гостевой чат не получает доступ к репозиториям, а yCode не публикует изменения в производство сам по себе.
Для команды также важен контур выполнения и обработки кода. Как сравнивать варианты размещения корпоративного ИИ — отдельный вопрос архитектуры, а не автоматическое свойство любой задачи yCode.
Попробовать yCode — начните с небольшого исправления, которое можно проверить. yCode входит в экосистему «Виксора»; итоговое инженерное решение остаётся вашим.
