На протяжении десятилетий разработка программного обеспечения опиралась на опытных разработчиков, которые передавали знания от человека к человеку. По мере того, как ИИ меняет способы написания и сопровождения кода, эта культура унаследованной памяти, возможно, начнёт рушиться.
Бэкенд-инженер в страховой компании Hagerty Зеб Ларсон отмечает, что реальность такова: разработка программного обеспечения — это устная традиция, особенно на начальном этапе карьеры инженера, когда человек работает не с новым кодом, а, скорее всего, с устаревшей кодовой базой. В этот период специалисту приходится искать ответы не в документах, а у коллег. «Может быть, есть несколько страниц в вики, объясняющих известные проблемы, некоторые из которых были решены давно, а другие остались нерешёнными в кодовой базе. Кто-то мог оставить комментарий в самом коде, но обычно это предупреждение о том, что не следует что-то менять, иначе что-то другое сломается», — пишет он.
В итоге новичку приходится обращаться к опытным сотрудникам, которые работают достаточно давно, чтобы понимать, что происходит «под капотом».
При этом в теории все согласны с тем, что документация важна, но на практике она непоследовательна, устарела или вовсе отсутствует, отмечает инженер. Частично это объясняется простой инерцией. Написание документации обычно менее интересно, чем самого кода. Но это также идеологический аспект. Так, движение Agile возникло отчасти как реакция на чрезмерно документированную методологию Waterfall, и одна из основных ценностей Agile явно ставит во главу угла «работающее программное обеспечение, а не исчерпывающую документацию».
«Мы не рассказываем это как историю, и если кто-то попросит меня объяснить, почему мы написали именно хранимую процедуру, а не что-то другое, я не буду отвечать стихотворными стихами. Но устные традиции имеют обучающий компонент, и на этом уровне они воспроизводятся среди инженеров. Определённые шаблоны разработки программного обеспечения или реализации будут иметь приоритет над другими или наоборот (инженеры, как правило, используют фрагменты кода в качестве предостережения о том, чего делать не следует). Это важная часть обучения новых инженеров», — поясняет Ларсон.
Он приводит параллель с устными традициями передачи знаний в сообществах, но отмечает разницу — разработка программного обеспечения предполагает текучесть кадров среди инженеров-программистов. В результате происходит постоянная утечка знаний в предметной области. Это не только затрудняет адаптацию новых сотрудников, но значительно усложняет решение проблемы укоренившегося технического долга. Нанимать новых людей становится сложнее, а также повышается вероятность серьёзных ошибок.
«Поэтому заманчиво предположить, что генеративный ИИ заполнит этот пробел и решит эту проблему за нас. В конце концов, даже если вы не хотите использовать большую языковую модель (LLM) для работы с устаревшей кодовой базой — а причин для этого предостаточно — генерация документации к самой кодовой базе может показаться решением проблемы отсутствия другой письменной информации. LLM, безусловно, могут кратко изложить код», — пишет инженер.
Но он указывает на проблемы в этом процессе: галлюцинации ИИ, а также написание документации, которое обычно является частью мыслительного процесса. LLM же может кратко изложить, что делает кодовая база, но не объяснит, почему разработчик выбрал один подход вместо другого.
«Решение заключается в возвращении к письменному слову, или, по крайней мере, к тому, что может сработать для нас. Так же, как в технологиях существует культура устной речи, существует и культура письменного слова, и они могут сосуществовать. Один из лучших примеров произошел во время разработки ARPANET, где инженеры создали культуру вокруг RFC, или запросов на комментарии: неформальных меморандумов, используемых для обсуждения стандартов, проблем, предложений и передовых методов. Некоторые документы были серьёзными, некоторые юмористическими, но все они были написаны для других инженеров. Представьте, что вы относитесь к документации так же: не как к бюрократическому домашнему заданию для менеджеров, а как к средству коммуникации с людьми, которые позже унаследуют ваш код», — заключает Ларсон.
Между тем исследователи обнаружили, что в 2026 году разработчики уже не смогут отказаться от инструментов для программирования с использованием ИИ. Это может создать дополнительные проблемы с сопровождением кода.
Автор: maybe_elf
