Почему я обсуждаю с ИИ не только код
Когда VOP стала медленно отвечать на запросы, ответ нашёлся не в коде. Нужно было разобраться, откуда приложение обращается к базе данных.
При разработке VOP мы столкнулись с заметными задержками. Можно было продолжать искать участок кода, который стоило переписать. Но прежде мы решили проверить, на что именно уходит время.
Мы проверили, где запущены компоненты и каким путём их запросы доходят до базы данных. Когда изменили размещение компонентов, значительная часть задержек исчезла. Ещё один просмотр исходников вряд ли дал бы тот же ответ: причину стоило искать не только в коде.
С HoursKZ вопрос иногда возвращался ко мне с другой стороны. Я просил написать функцию, получал в точности то, что описал, и только тогда замечал, чего в задании не хватало. В такой момент править код рано. Сначала нужно понять, какого поведения я вообще жду от программы.
Когда я только начинал работать с агентами, мне проще всего было объяснить их пользу на примере программирования. Вот задача, вот изменения, вот что происходит при запуске. Но реальная задача редко остаётся в границах одной специальности. Следом за вопросом о функции возникает вопрос об архитектуре. Неудачный тест возвращает меня к требованию. Проблема после развёртывания заставляет смотреть на сеть, а не на исходники.
Раньше для перехода от разработки к тестированию или внедрению мне нередко приходилось отдельно описывать задачу следующему участнику. Эти описания по-прежнему полезны, когда работают несколько человек. Но теперь я сам могу проверить больше, не начиная каждый раз с пересказа всей истории. Это не значит, что я заменил команду специалистов. Я просто раньше вижу последствия своих решений.
Но ошибочную идею ИИ тоже может быстро довести до работающего кода. И тесты подтвердят, что программа делает именно то, о чём я попросил. А правильно ли я поставил задачу? За это по-прежнему отвечаю я, не агент.