Комментарии 5
Если использовать нейросети как референс, то скорость тоже растет, спектр выбора решений обогащается, но никаких таких проблем нет.
Тут все просто - нейросети должны помогать человеку который работает на бизнес, по крайней мере в работах с высоким процентом творчества в основе. А не самому бизнесу.
Измерьте метрики после внедрения: сравните с начальными показателями.
Ну и как успехи?
Искусственный интеллект сгенерировал рабочий вариант за 4 часа вместо недели работы. Звучит как успех, но когда передали код команде продуктовой разработки, выяснилось: около 60% пришлось переписывать. Нейросеть продублировала методы, которые уже существовали в других частях системы, проигнорировала архитектурные паттерны проекта и запихнула всю логику в один файл на 800 строк.
Вопрос:
Почему так случилось, что можно сделать?
Ответ ИИ:
🤖 Почему ИИ подвёл команду (и как это исправить)
Ситуация классическая: ИИ отлично справляется с написанием кода в вакууме, но совершенно не чувствует контекст и архитектуру конкретного проекта. Для него ваша кодовая база — это «черный ящик», если вы не дали к нему доступ.
🚩 Почему это произошло?
Отсутствие контекста: Нейросеть видела только вашу задачу, но не знала о существовании готовых методов в других файлах. Она «изобрела велосипед», потому что не знала, что он уже стоит в гараже.
Проблема «длинного контекста»: ИИ проще выдать результат в одном файле, чем проектировать связи между десятью модулями. Разрезание логики на части требует понимания структуры папок и правил импорта, которые вы, скорее всего, не описывали в промпте.
Отсутствие Linter-ов и правил: ИИ не знаком с вашим стайл-гайдом или архитектурными паттернами (например, SOLID или Clean Architecture), если они не прописаны в системных инструкциях.
🛠 Что можно сделать?
Контекстная подача (RAG для кода): Используйте инструменты вроде Cursor или плагины (например, GitHub Copilot с индексацией репозитория). Они позволяют ИИ «читать» весь проект перед генерацией, что резко снижает дублирование функций.
Метод «Сначала архитектура»: Не просите ИИ сразу писать код. Сначала попросите его составить план реализации: какие файлы создать, какие методы использовать. Команда должна утвердить этот план, и только потом давать команду на генерацию по частям.
Модульные промпты: Разбивайте задачу. Вместо «напиши фичу» говорите: «Используй метод X из файла Y, создай новый класс в папке Z и вынеси бизнес-логику в отдельный сервис».
Спецификации (Rules): Создайте файл
.cursorrulesили аналогичный, где жестко прописаны правила:«Не писать файлы длиннее 200 строк»
«Использовать только Dependency Injection»
«Всегда проверять папку /utils на наличие дублей»
Хотите подберем конкретные инструменты или настроим шаблон системного промпта, чтобы ИИ соблюдал ваши архитектурные правила?
Кстати, интересно то, что я пробовал все эти варианты и... это не помогло)
«Не писать файлы длиннее 200 строк» - клауд обожает это игнорировать
Пока, все что помогает в практике это ИИ агенты, вот за счет них получается изолировать и разбить контекст и тогда немного лучше
Но в остальном проблема контекста пока слишком явная
ИИ в разработке: почему ваш код стал хуже, хотя команда стала писать быстрее