Разработка с AI в начале 2025. Ограничения и решения (2/2) Вероятностность Это вообще общее свойство работы с текущими ИИ - что сработало 9 раз, на 10й может сломаться, и __это норма__, нужно попробовать еще раз (возможно, переформулировав запрос). Благо, что тот же Cursor Composer делает снапшоты и можно быстро откатить его изменения, ну и в крайнем случае гитом ведь все же пользуются, верно? :) Также стоит самому проверять то, что вам выдает ИИ, причем для того, чтобы понять, всё ли в порядке, даже не всегда нужно читать код - тот же Cursor довольно подробно описывает сделанные изменения человеческим языком, и этого часто хватает, чтобы понять, всё ли идет как вы планировали. Не та стилистика кода По умолчанию современные модели будут пытаться подстраиваться под стиль кода в вашем проекте (с переменным успехом), но если проект новый - будет выбран какой-то из стилей, с которыми модель чаще всего сталкивалась при обучении. Что делать? Не стесняться сказать модели, какой стиль нужно использовать, если его можно кратко описать в чате. Если кратко на ходу не получится описать - можно сделать отдельный файл, расписать там правила для стиля подробно, и каждый раз этот файл класть в контекст, чтобы модель про него знала и учитывала при написании кода. Для этого, кстати, хорошо подходит файл .cursorrules в Cursor, который сам автоматически включается в контекст. ИИ не понимает проект Современные нейронки довольно неплохо ухватывают суть кода, но если мы говорим о каком-то отдельном модуле или нетривиальном проекте, то общая картина может потеряться. Что делать? Точно так же, как и со стилем кода, в контекст модели можно класть документацию по проекту, причем желательно в простом текстовом формате навроде Markdown. А если у вас есть публичная ссылка на документацию - можно её вставить в чат. Есть более продвинутые подходы - когда по вашему запросу перед тем, как его отправить LLM, сторонняя система его сначала использует для поиска релевантной документации в базе знаний проекта, выделяет нужные куски оттуда и готовит их для включения в контекст (подходы RAG, Knowledge Graph, etc), но вот пока что этот тулинг существует отдельно от AI-редакторов, что делает этот вариант не очень удобным, но осуществимым. Ждём такой встроенной фичи, это явно упростит жизнь на сложных и больших проектах. У меня реально большой проект Ключевые слова тут такие: планирование, декомпозиция, модульность, чёткие контракты, документация - т.е. всё то же самое, что нужно и людям, работающим на большом проекте. Из этого всего проистекает набор частично оформившихся и пока что меняющихся на ходу практик, которые упрощают работу над большими проектами, но это уже тема отдельного поста. Заранее скажу, что тут не стоит надеяться на чудо - с наскоку фичу в большом проекте или какой-то широкий рефакторинг сделать не получится, нужно быть аккуратным в том, как вы распорядитесь ограниченным контекстом модели. Моя модель меня не слушается :) Нууу, с ними такое бывает :) Особенно когда контекст кончается или в нем накопилась куча нерелеватных текущей задаче данных. Впрочем, это в целом беда некоторых моделей __попроще__ - тот же DeepSeek, к примеру, менее управляем, чем Sonnet. Что делать? * давать модели более чёткие, формальные инструкции, особенно для нетривиальных задач; * давать больше сведений о том, для чего и почему что-то делается, с чем связан функционал; * вовремя избавляться от старого контекста, переходя в новый чат. #ai #work #development