"Разработка с AI в начале 2025. Ограничения и решения (1/2) Нет инструментов без своих минусов, так что в этой, финальной части, обсудим текущие проблемы и ограничения, которые чаще всего встречаются в AI-разработке, а также способы их обойти или решить. Ограниченность длины контекста Проявляется в том, что не весь ваш код и документация могут быть ""осознаны"" и учтены, так что в ответ модель запросто может начать фантазировать о тех частях проекта, которые она ""не видит"", забывать тот код, который сама же написала и терять логические связи между разными участками кода. Последнее особенно ярко заметно на очень длинных контекстах, которые не являются ""честными"" (см. прошлый пост с подробностями). Что делать? * не пытаться засунуть в контекст сразу весь проект, если размер контекста этого не позволяет; * дробить проект на модули и разрабатывать их по отдельности - это в целом полезная практика; * иметь четко прописанные контракты между модулями (Swagger/OpenAPI, JSON Schema, интерфейсы в коде и т.п.), которые нужно класть в контекст; а также полезно иметь интеграционные тесты. Слишком длинные чаты Если вы пишете код в том же Cursor (__и даже если почему-то до сих пор в веб-интерфейсе ChatGPT__), вы наверняка сталкивались с тем, что спустя некоторое время модель начинает путаться в показаниях и отвечать все хуже и хуже, а иногда даже удалять нужный код. Это, во-первых, может быть связано с тем, что весь ваш чат перестал влезать в контекст, а во-вторых, если вы переиспользуете один и тот же чат для разных задач, то происходит замусоривание контекста и модель может начать пытаться связать между собой какие-то не относящиеся друг к другу факты, попавшие в этот контекст. Что делать? * по-хорошему, один чат в Cursor Chat - один мелкий фикс или серия фиксов связанного функционала; * в Cursor Composer - один чат на фичу / большое изменение; * если чат даже по одной фиче стал слишком большим - просите модель описать те изменения, которые были сделаны в рамках этого чата, идите с этим описанием в новый чат и продолжайте работу там. Устаревший код Нередко бывает, что для какой-то либы LLM предлагает поставить её старую версию и/или пишет код для старой версии. Тут дело в том, что у каждой LLM есть knowledge cutoff date - та дата, которой ограничен собранный для нее датасет. Ну т.е. для тренировки условной ChatGPT 4o данные могли собрать из Интернета еще года полтора назад, потом полгода ее на этих данных учили, выпустили, а мы до сих пор ей пользуемся. Добросить в неё новые знания - вычислительно и финансово весьма накладно, так что модели не так часто обновляются. Что делать? * если документация не очень большая (помним про размер контекста), можно прям целиком её копипастнуть в чат с LLM или, что удобнее, дать ссылку на страницу документации в том же Cursor Composer - он сам ее скачает, распарсит и положит в контекст для модели; * попробовать использовать символ @Web в Cursor - он запускает поиск релевантной вашему сообщению инфы в сети и потом включает результаты поиска в текущий контекст; * переключиться на модель поновее - как правило, у недавно вышедших моделей cutoff date позднее и знания более актуальные; * не использовать самые новые версии библиотек :) Не, ну кроме шуток - это нередко себя оправдывает. К примеру, Angular и в прошлом году уже был __достаточен__ для подавляющего большинства проектов, и большого профита от его свежего релиза скорее всего не получить, а вот бороться с LLM придется. __Конечно, нужно выбирать те версии, которые не совсем заброшены и хотя бы всё ещё получают обновления безопасности.__ Языки программирования тоже лучше выбирать как можно более массовые и стабильные, по тем же причинам. В особо тяжелых случаях модель вообще может не знать конкретного языка / фреймворка или иметь очень мало по нему данных для того, чтобы писать рабочий код. В этом случае придётся либо все-таки писать код самому, либо креативно сочетать подходы выше. #ai #work #development"