Теория эволюции программного обеспечения в эпоху ИИ

Сегодня во многих компаниях большая часть принятия и исполнения решений, проверки результатов и совершенствования процессов происходит в программных системах. Точки взаимодействия с клиентами, изменения цен и контрактов, корректировка поставок и запасов, сбор и анализ журналов, а также внутренние операционные рабочие процессы — всё это глубоко зависит от ПО. Это уже не тот этап, когда ИТ просто были внедрены; сама работа бизнеса привязана к состоянию его ПО, а возможность обновления ПО стала эквивалентной возможности обновлять бизнес.

Эта ситуация не ограничивается конкретными отраслями. Компании разных отраслей и масштабов, работающие с определённым уровнем скорости и сложности, больше не могут функционировать без ПО в своей основе. Поскольку внешние условия меняются быстрее и циклы «решение — исполнение» учащаются, способность меняться сама становится конкурентным фактором. Когда изменения в ценности для клиента, условиях обслуживания, операционных ограничениях, нормативных требованиях и структурах затрат совпадают, бизнес, который не может обновить своё ПО, не может преобразовать решения в действия, не может вносить исправления и в конечном итоге останавливается.

В этой среде наблюдается множество случаев, когда обновления ПО становятся узким местом для принятия бизнес-решений и изменений политики. Решения могут быть приняты, но структурные изменения, необходимые для их реализации, не могут быть завершены вовремя, что сужает круг инициатив, которые можно реально протестировать.

Чем больше времени занимают обновления ПО, тем больше становится расстояние между решением и исполнением. За это время внешние условия продолжают меняться. В результате всё больше решений остаются невыполненными, а диапазон деятельности бизнеса постепенно сужается.

Когда мы смотрим на ПО, которое использовалось в течение длительного периода времени, редко можно найти системы, которые остаются в исходном состоянии. Добавляются функции, меняются конфигурации, эксплуатация корректируется, и ПО приобретает форму, совершенно отличную от его первоначального дизайна. Редко бывает, чтобы ранние спецификации или проектная документация полностью соответствовали реалиям реализации и эксплуатации годы спустя. Это не означает, что первоначальный замысел был бессмысленным; скорее, это отражает наблюдение о том, что условия, принятые вначале, трудно сохранить в течение длительных периодов эксплуатации.

Поскольку ПО продолжает использоваться, задачи и решения, которые изначально не предполагались, становятся частью повседневной эксплуатации. Меняются поведение пользователей, объём и смысл данных, а также связи с окружающими системами. Накапливается дополнительная обработка, реорганизация, замены и обходные пути. То, что поначалу кажется небольшим исключением, со временем становится нормой, и эти новые нормы всё сильнее воздействуют на внутреннюю структуру. Со временем дизайн, который когда-то был простым, становится более сложным, поскольку он учитывает требования реального мира.

Также редко одни и те же люди остаются ответственными на протяжении всего срока службы системы. Разработчики и операторы меняются, организационные структуры развиваются, роли перераспределяются. Даже когда документация сохраняется, контекст и исходные допущения прошлых решений передаются не полностью. Теряется не объём информации, а набор условий, при которых предыдущие решения имели смысл. Когда эти предположения исчезают, один и тот же текст больше не приводит к одним и тем же выводам. Изменения становятся более осторожными, количество локальных обходных путей увеличивается, а общая согласованность постепенно ухудшается.

Эти изменения не возникают в результате конкретных сбоев или исключительных обстоятельств. Подобные закономерности неоднократно наблюдаются в разных организациях, отраслях и технических областях. Их объединяет то, что ПО используется в течение длительных периодов времени, в то время как окружающие условия продолжают меняться. Хотя природа этих изменений различается в зависимости от контекста, неизменным остаётся сам факт непрерывных изменений.

Небольшие различия в предположениях накапливаются со временем. Корректировки, которые когда-то могли быть внесены в рамках повседневной эксплуатации, в конечном итоге требуют структурного пересмотра. На этом этапе сложность и масштаб изменений возрастают. По мере расширения диапазона воздействия растут затраты на проверку, откат становится сложнее, а принятие решений замедляется. Когда решения принимаются медленно, компании больше не могут тестировать то, что хотят попробовать. Проблема здесь не в низком качестве, а в заторможенном обучении — и чем быстрее меняется внешняя среда, тем разрушительнее последствия.

Многие разработки традиционно следовали модели, в которой дизайн стараются максимально завершить до начала реализации. Этот подход оказался эффективным для достижения консенсуса, обеспечения разделения труда и управления масштабными проектами. В средах, где затраты на внедрение высоки, а экспериментирование дорого, ранняя фиксация дизайна была практичным выбором, а проектирование служило для предварительного снижения сложности.

Однако этому подходу присущи ограничения временной структуры. С момента завершения проектирования заложенные в него условия начинают меняться. Чем больше разрыв между завершением проектирования и реализацией, тем больше расхождение между предположениями и реальностью. Когда условия быстро меняются, это расхождение может стать значительным к моменту завершения работы системы. Изменения часто происходят не в мелких деталях спецификации, а в фундаментальных приоритетах, эксплуатационных ограничениях или значении данных.

Это не означает, что проект был неправильным. Во многих случаях это было лучшее решение на тот момент. Проблема возникает, когда не учитывается тот факт, что предположения будут меняться с течением времени. Если корректировка после завершения не встроена, систему будет сложно обновить в момент её завершения. Когда завершение рассматривается как конечная точка, последующие изменения обрабатываются как исключения, и накапливаются как поздние дополнения. Со временем локальные исправления множатся, структура становится жёстче, а скорость обучения бизнеса снижается.

Такой подход к развитию возник по понятным причинам. Высокие затраты на реализацию и тяжёлое бремя экспериментов сделали необходимым раннее планирование. Способность оценивать условия, организовывать зависимости и заранее определять полную систему играла решающую роль в таких средах. Достижение консенсуса, ранняя проработка рисков и структурированное разделение труда были практическими потребностями.

По мере изменения условий меняется и то, в чём заключается ценность. Прошлые суждения, неудачи и корректировки не становятся недействительными. Вместо этого к ним обращаются и используют их по-новому. Опыт, полученный в ходе обзоров проектов, больше не используется для точного прогнозирования будущего, а используется для определения того, где системы могут выйти из строя при изменениях. Практические уроки позволяют понять, какие основы должны оставаться неизменными, а какие области должны оставаться гибкими. Прошлый опыт не отбрасывается; он используется повторно.

Поскольку такое повторное использование становится возможным, ценность опыта часто увеличивается, а не уменьшается. В быстро меняющихся условиях неправильные суждения быстро усиливаются. Более низкие затраты на эксперименты означают больше попыток, в том числе ошибочных. В результате качество расстановки приоритетов и выбора направления оказывает большее влияние на результаты.

В последние годы условия разработки заметно изменились. Стоимость внедрения и экспериментирования снизилась, а время, необходимое для превращения гипотез в проверяемые формы, сократилось. Частично этот сдвиг обусловлен широким распространением ПО на базе искусственного интеллекта, которое напрямую поддерживает генерацию и модификацию кода. Эти инструменты снижают первоначальные затраты на проверку реализаций и позволяют опробовать, отбросить и реструктурировать проекты.

Здесь важно не то, будет ли принят ИИ, а то, что условия изменились. Когда условия меняются, меняются и структуры, эффективно функционирующие в них.

Важно отметить, что речь не идёт о противопоставлении разработки с помощью ИИ разработке, выполняемой человеком. Происходит сближение человеческих суждений, таких как расстановка приоритетов, структурные решения и контекстуальное понимание, с генерацией и модификацией кода с помощью ИИ. Люди решают, что попробовать и где изменить; ИИ снижает стоимость реализации этих решений. Благодаря этому сотрудничеству стали возможны эксперименты и обучение с ранее недостижимой скоростью.

В результате разработка, которая постоянно обновляет ПО в соответствии с изменениями в бизнесе, впервые стала реалистичным вариантом.

В этих условиях структуры, допускающие корректировку постфактум, более управляемы, чем те, которые пытаются зафиксировать всё заранее. По мере роста масштаба и развития требований возможность пересматривать и изменять структуру становится обязательным условием. Это не означает отказ от дизайна. Это означает сокращение объёма неизменяемой основы, чёткое определение того, что должно оставаться гибким, и сохранение возможности постепенно реорганизовывать структуру с ясными приоритетами. Фундаментальный дизайн становится более важным, а не менее важным.

По мере масштабирования систем инфраструктура неизбежно заменяется. Конфигурации, которых когда-то было достаточно, требуют механизмов избыточности, разделения, распределения, наблюдаемости и восстановления. Продолжающаяся эксплуатация требует реорганизации и расширения функций. В реальных средах обновления, понижения версий, откат, поэтапная миграция, параллельная работа и частичная замена — это рутинные действия, а не исключительные инциденты. Структуры, не поддерживающие как продвижение вперёд, так и откат, увеличивают риск и затраты с каждым изменением, что в конечном итоге приводит к полной остановке обновлений.

По этой причине структуры ПО должны поддерживать обратимость и заменяемость. Когда границы неясны и системы растут в одном направлении, изменения распространяются широко, проверка теряет точность, а откат затруднителен. Чётко определённые границы и модульные сменные блоки позволяют продолжать обучение, несмотря на изменения.

Эти решения не могут быть оставлены на усмотрение только индивидуальной изобретательности. Определение того, что остаётся неизменным, что остаётся гибким и какие изменения приемлемы, следует рассматривать как общие исходные договорённости. Это требует большего, чем просто выбор инструментов или стандартов кодирования; это требует общего тактического понимания. Там, где такое общее понимание отсутствует, обновления начинают зависеть от отдельных людей, скорость снижается и обучение прекращается.

Каждый раз, когда условия меняются, к ПО и бизнесу добавляются новые ограничения. Хотя прошлые проекты и реализации больше не могут применяться напрямую, это не отменяет лежащий в их основе опыт.

Суждения, сформированные в результате предыдущих изменений (понимание того, где системы ломаются, где возникают узкие места и как далеко распространяются изменения), продолжают использоваться, когда условия снова меняются. Даже когда форма меняется, эти суждения вновь всплывают на поверхность при принятии решения о том, что делать дальше и куда вмешаться.

В современных средах разработки сочетание человеческого понимания ситуации и реализации с помощью искусственного интеллекта позволяет применять такой опыт с гораздо более короткими интервалами. Накопленные знания проявляются в качестве суждений и напрямую переходят в последующие реализации и проверки.

В результате системы не перестраиваются с нуля при каждом изменении, а прошлые формы не сохраняются жёстко. Вместо этого опыт используется повторно по мере изменения условий, и ПО развивается соответствующим образом.

Изменения будут продолжаться. Появятся новые технологии и ограничения. Но накопленный опыт не будет потерян. По мере роста скорости и частоты повторного использования опыта его ценность всё непосредственнее и стабильнее отражается в результатах.