Чему я научился при создании уровня проектной аналитики для разработки с помощью ИИ. Что-то странное происходит с разработкой с помощью ИИ. ИИ становится очень хорош в написании кода. Он может проверять репозиторий, понимать работу...
Чему я научился при создании уровня проектной аналитики для разработки с помощью ИИ.
Что-то странное происходит с разработкой с помощью ИИ.
ИИ становится очень хорош в написании кода.
Он может проверять репозиторий, понимать функции, генерировать тесты, рефакторить файлы и даже вносить довольно сложные изменения.
Но есть еще одна часть разработки программного обеспечения, которая не встроена в кодовую базу:
Почему было принято такое решение?
Почему мы выбрали эту архитектуру?
Почему этот обходной путь все еще здесь?
Почему эту, казалось бы, простую функцию нельзя изменить?
Что мы уже пробовали?
Какое ограничение мы пытались обойти?
Что на самом деле просил пользователь?
И, пожалуй, самое главное:
Что мы узнали, когда в последний раз прикасались к этой части системы?
Эта информация часто разбросана по истории Git, проблемам, документации, Slack, PR-дискуссиям и разговорам об искусственном интеллекте.
Код выживает.
Аргументация часто этого не делает.
Проблема не только в памяти
Сначала я думал, что это в основном проблема с памятью ИИ.
Дайте ИИ больше контекста.
Сохраняйте больше разговоров.
Индексируйте больше файлов.
Получите лучшие куски.
Но чем больше я над этим работал, тем больше понимал, что это возможно.