Действие через тестирование
там в эксперименте из предыдущего поста исследовалась служба технической поддержки, в которой по сути максимизирован вариант технологии "действие через тестирование" - попробуйте выдернуть шнур, нажать кнопку, не получилось? ну тогда разверните роутер на север.
"Действие через тестирование" - это идеальный вариант для нейронок, особенно, если в профессии уже используется такой подход. Другим профессиям такое не всегда подойдет.
У программистов такая разновидность рабочего процесса называется TestDrivenDevelopment. Сначала пишем тесты для функции, затем саму функцию.
На словах этот процесс все очень уважают, но реально применяют мало, по ряду причин. Если нейронка сможет быстро выплевывать функции, а затем еще и читать сообщения об ошибках (а gpt4 такое умеет, но ни один процесс TDD я для нее еще не разработал), то это вариант.
И вторая нейронка пускай пишет функции тестов, так победим. Шутка, это не сработает быстро, потому что для перехода на такой стиль разработки нужно полностью переключить мозги, идти совсем по другой дороге.
Сид Майер в автобиографичной книге "Жизнь в мире компьютерных игр" признавался, что он не любит даже технические задания, он творец, для которого код - как глина (его сравнение), которое можно то добавлять, то удалять в процессе создания игры.
Разработка программ через тестирование - это максимальная стадия развития технического задания, не в том смысле, что это должен сделать клиент, а в том, что программист должен развить задание на фичу до полного предварительного описания всех нюансов и диапазонов ответов. Я такой стиль мышления встречал крайне редко.
Разработка через тестирование, впрочем, очень хороша и посильна каждому для отдельных экзотических функций, которые как ни пиши, а читать через полгода будет очень тяжело. Что-нибудь вроде разворота многомерного массива в сложном пространстве через заданную ось (шутка, не писал никогда такого). Тут тесты просто необходимы.
"Действие через тестирование" - это идеальный вариант для нейронок, особенно, если в профессии уже используется такой подход. Другим профессиям такое не всегда подойдет.
У программистов такая разновидность рабочего процесса называется TestDrivenDevelopment. Сначала пишем тесты для функции, затем саму функцию.
На словах этот процесс все очень уважают, но реально применяют мало, по ряду причин. Если нейронка сможет быстро выплевывать функции, а затем еще и читать сообщения об ошибках (а gpt4 такое умеет, но ни один процесс TDD я для нее еще не разработал), то это вариант.
И вторая нейронка пускай пишет функции тестов, так победим. Шутка, это не сработает быстро, потому что для перехода на такой стиль разработки нужно полностью переключить мозги, идти совсем по другой дороге.
Сид Майер в автобиографичной книге "Жизнь в мире компьютерных игр" признавался, что он не любит даже технические задания, он творец, для которого код - как глина (его сравнение), которое можно то добавлять, то удалять в процессе создания игры.
Разработка программ через тестирование - это максимальная стадия развития технического задания, не в том смысле, что это должен сделать клиент, а в том, что программист должен развить задание на фичу до полного предварительного описания всех нюансов и диапазонов ответов. Я такой стиль мышления встречал крайне редко.
Разработка через тестирование, впрочем, очень хороша и посильна каждому для отдельных экзотических функций, которые как ни пиши, а читать через полгода будет очень тяжело. Что-нибудь вроде разворота многомерного массива в сложном пространстве через заданную ось (шутка, не писал никогда такого). Тут тесты просто необходимы.