Поучаствовал некоторое время назад в
дискуссии на эту тему. Процитирую тут отправную точку:
TDD - это примерно так:
https://xkcd.com/2048/ :)
Тесты - фиксированные точки, код - кривая, которая должна через них проходить.
Я там дальше в ответ что-то мямлил про оценку качества работы программы, забыв, что решение проблемы находится выше уровня, на котором она сформулирована. Поэтому попробуем подняться выше: зачем вообще органический программист пишет программу? Берём обычный для индустрии случай: программист пишет программу для кого-то другого, для заказчика. Разберём взаимодействие заказчика и программиста в этой рабочей ситуации. Чего здесь хочет заказчик? Заказчик хочет, чтобы ему сделали "Зашибись". Уподобим это "Зашибись" некоторой кривой из цитаты выше. Таким образом, в воображении заказчика существует некоторая кривая, которую заказчик хочет увидеть воплощённой в виде программы. И вот заказчик приходит к программисту и говорит: "Программист, можешь сделать мне Зашибись?"
А дальше начинаются варианты:
1) Программист отвечает: "Ни слова больше!" и уходит делать Зашибись. Этот вариант идеален с т.зр. заказчика на этапе от начала работы до приёмки результата: от заказчика требуется только регулярно оплачивать рабочее время программиста. К сожалению на этапе приёмки результата этот вариант гораздо менее идеален: велика вероятность, что получившаяся кривая с т.зр. заказчика будет не Зашибись, а, в лучшем случае, Норм, а то и Ну Такоэ.
2) Программист, прежде чем начать кодить, долго и нудно выясняет у заказчика, что такое "Зашибись". Практически требует, чтобы заказчик ему, программисту, дал математическую формулу, описывающую ту кривую, которая у заказчика в воображении. А заказчик, может быть, не умеет в математические формулы! Заказчик, может быть, и декартову систему координат забыл уже. Да и вообще, если заказчику нужно выводить эту формулу самому, за что он программисту деньги платит? В общем, такая модель взаимоотношений называется "водопадная модель разработки", и её давно уже прокляли и похоронили.
3) Программист выясняет у заказчика несколько точек, которые не должны лежать слишком далеко от Зашибись-кривой, и интерполирует по ним, как умеет, после чего показывает результат заказчику. Заказчик видит отрезок кривой, который местами похож на определённый отрезок Зашибись-кривой, и в ответ даёт программисту ещё несколько точек, по которым программист должен поправить имеющийся отрезок там, где этот отрезок слишком отклоняется, и продолжить кривую дальше. Программист снова интерполирует уже с новыми данными, получая новый отрезок кривой, который или длиннее, или больше похож на Зашибись-кривую. Так продолжается итерация за итерацией, пока заказчик готов платить за то, чтобы ещё на шаг приблизиться к Зашибись. Это называется "Agile" разработка. Главное преимущество её по сравнению с "водопадной" в том, что заказчик гораздо быстрее получает какой-то результат, а потом так же быстро получает всё новые и новые улучшения этого результата.
В общем, к чему я веду.
Первое поколение автоматических программистов, конечно же, не сможет работать по первому варианту. Хотя с развитием технологий дойдёт и до этого:
Click to view
От второго варианта отказались сами же органические программисты. С чего бы автоматическим программистам работать по давно дискредитированным принципам? Это ответ тем скептикам, которые в дискуссии по ссылке упирают на то, что машина, мол, не будет чего-то там "понимать". Понимание переоценено.
Ну а в способности нейросети интерполировать не сомневаются, кажется, даже скептики. Причём, нейросеть интерполирует гораздо быстрее и не грузит заказчика, пытаясь выудить из него концептуализированные, непротиворечивые и полные требования.
Я вообще не понимаю, откуда у органических программистов берутся ожидания, что автоматические программисты будут облегчать органическим программистам работу. Смысл автоматизации - в снижении издержек заказчика.