Прочитал пост. Методика интересная, но она вызывает много вопросов о практической стороне и реальных ограничениях. Хотелось бы обсудить эти подводные камни.
Когнитивная нагрузка. Первое, что бросается в глаза - ты меняешь одну сложную задачу (написание кода) на другую, возможно, еще более сложную (постоянный надзор за LLM). Нужно держать в голове весь контекст диалога, следить, чтобы модель не «уплыла», и вручную ее корректировать. Не получается ли так, что это утомляет даже больше, чем просто сесть и написать код самому?
Отладка «черного ящика». Второй момент - отладка. Рано или поздно LLM будет клясться, что всё готово, а код будет падать или содержать скрытые баги. Все равно ведь придется лезть в сгенерированный код, который ты не писал. Насколько тяжело дебажить такую систему, особенно если логика у машины получилась запутанная и нечеловеческая?
Потолок сложности. И третье - границы применимости. Твой пример с деплоем - понятная, изолированная задача. А что насчет более глубоких вещей, вроде рефакторинга ядра системы, который затрагивает десятки взаимосвязанных файлов? Или оптимизации производительности, где важна каждая мелочь? Есть сильное ощущение, что на таких задачах этот подход просто развалится, и агент утонет в контексте. Пробовал уже что-то подобное?
Пока это выглядит как очень мощный инструмент для решения стандартных или хорошо изолированных задач, но есть большие сомнения в его применимости для долгосрочной разработки сложной бизнес-логики. Интересно было бы услышать твое мнение именно по этим узким местам.
Information
Rating
10,168-th
Location
Лимассол, Government controlled area, Кипр
Registered
Activity
Specialization
System Software Engineer, Chief Technology Officer (CTO)
Прочитал пост. Методика интересная, но она вызывает много вопросов о практической стороне и реальных ограничениях. Хотелось бы обсудить эти подводные камни.
Когнитивная нагрузка. Первое, что бросается в глаза - ты меняешь одну сложную задачу (написание кода) на другую, возможно, еще более сложную (постоянный надзор за LLM). Нужно держать в голове весь контекст диалога, следить, чтобы модель не «уплыла», и вручную ее корректировать. Не получается ли так, что это утомляет даже больше, чем просто сесть и написать код самому?
Отладка «черного ящика». Второй момент - отладка. Рано или поздно LLM будет клясться, что всё готово, а код будет падать или содержать скрытые баги. Все равно ведь придется лезть в сгенерированный код, который ты не писал. Насколько тяжело дебажить такую систему, особенно если логика у машины получилась запутанная и нечеловеческая?
Потолок сложности. И третье - границы применимости. Твой пример с деплоем - понятная, изолированная задача. А что насчет более глубоких вещей, вроде рефакторинга ядра системы, который затрагивает десятки взаимосвязанных файлов? Или оптимизации производительности, где важна каждая мелочь? Есть сильное ощущение, что на таких задачах этот подход просто развалится, и агент утонет в контексте. Пробовал уже что-то подобное?
Пока это выглядит как очень мощный инструмент для решения стандартных или хорошо изолированных задач, но есть большие сомнения в его применимости для долгосрочной разработки сложной бизнес-логики. Интересно было бы услышать твое мнение именно по этим узким местам.