Разработка с AI в начале 2025. Ограничения и решения (2/2)

Вероятностность
Это вообще общее свойство работы с текущими ИИ - что сработало 9 раз, на 10й может сломаться, и это норма, нужно попробовать еще раз (возможно, переформулировав запрос). Благо, что тот же Cursor Composer делает снапшоты и можно быстро откатить его изменения, ну и в крайнем случае гитом ведь все же пользуются, верно? :)

Также стоит самому проверять то, что вам выдает ИИ, причем для того, чтобы понять, всё ли в порядке, даже не всегда нужно читать код - тот же Cursor довольно подробно описывает сделанные изменения человеческим языком, и этого часто хватает, чтобы понять, всё ли идет как вы планировали.

Не та стилистика кода
По умолчанию современные модели будут пытаться подстраиваться под стиль кода в вашем проекте (с переменным успехом), но если проект новый - будет выбран какой-то из стилей, с которыми модель чаще всего сталкивалась при обучении.

Что делать?
Не стесняться сказать модели, какой стиль нужно использовать, если его можно кратко описать в чате.
Если кратко на ходу не получится описать - можно сделать отдельный файл, расписать там правила для стиля подробно, и каждый раз этот файл класть в контекст, чтобы модель про него знала и учитывала при написании кода.
Для этого, кстати, хорошо подходит файл .cursorrules в Cursor, который сам автоматически включается в контекст.

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

Что делать?
Точно так же, как и со стилем кода, в контекст модели можно класть документацию по проекту, причем желательно в простом текстовом формате навроде Markdown.
А если у вас есть публичная ссылка на документацию - можно её вставить в чат.

Есть более продвинутые подходы - когда по вашему запросу перед тем, как его отправить LLM, сторонняя система его сначала использует для поиска релевантной документации в базе знаний проекта, выделяет нужные куски оттуда и готовит их для включения в контекст (подходы RAG, Knowledge Graph, etc), но вот пока что этот тулинг существует отдельно от AI-редакторов, что делает этот вариант не очень удобным, но осуществимым.
Ждём такой встроенной фичи, это явно упростит жизнь на сложных и больших проектах.

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

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

Заранее скажу, что тут не стоит надеяться на чудо - с наскоку фичу в большом проекте или какой-то широкий рефакторинг сделать не получится, нужно быть аккуратным в том, как вы распорядитесь ограниченным контекстом модели.

Моя модель меня не слушается :)
Нууу, с ними такое бывает :) Особенно когда контекст кончается или в нем накопилась куча нерелеватных текущей задаче данных.
Впрочем, это в целом беда некоторых моделей попроще - тот же DeepSeek, к примеру, менее управляем, чем Sonnet.

Что делать?
* давать модели более чёткие, формальные инструкции, особенно для нетривиальных задач;
* давать больше сведений о том, для чего и почему что-то делается, с чем связан функционал;
* вовремя избавляться от старого контекста, переходя в новый чат.

#ai #work #development