За последние 1-2 месяца ИИ системы разработки сделали довольно значительный шаг вперед, стали меньше ошибаться, подключили планирование и обратную связь. Задавались ли Вы вопросом почему? Казалось бы, ИИ взял лучшие шаги из разработки ПО, разбил разработку «на промпты» (по агентам) и — прорыв. Вы удивитесь, все это было раньше, и даже сама разработка ПО — это лишь это часть универсальной базы, причем даже сейчас еще не до конца реализованной. Спасибо П.К. Анохину. Начнем с картинки:
Из уважения, приведу оригинальные обозначения на схеме: Стадии: А — стадия афферентного синтеза; Б — стадия принятия решения; В — стадия формирования акцепторов результата действия и эфферентной программы самого действия. Г-Д — Получение результатов действия и формирование обратной афферентации для сличения полученных результатов с запрограммированными. ОА — обстановочная афферентация, ПА — пусковая афферентация.
Скрытый текст
На Хабре все есть, Обзор теорий сознания: теория функциональных систем П.К. Анохина, да вот только основной смысл функциональной системы (ФС) там сужен, такая же ситуация со статьей в википедии.
Функциональная система это универсальная штука, описывающая процессы на любом уровне (от клетки до всей популяции, а возможно и шире) и в любом контексте и окружении (от биологии и физиологии, до разработки ПО, управлении людьми и процессами, достижения своих целей и т.д.). Даже больше, утверждается, что если функциональная система не сформирована, то поддерживать, а чаще и достичь, значимый конечный полезный результат невозможно.
Естественно ФС может быть вложенной и представлять иерархию. И вот интересно принципы по которым организуется такая иерархия очень напоминают "вновь изобретенные" принципы ООП, но мы опустим это взаимодействие. Это отдельная тема, дальше мы ее будем касаться только вскользь.
Мотивация
Начало любой ФС — это мотивация. У предпринимателя, руководителя или тимлида мотивация часто это признание заслуг. Вариантом мотивации может быть так же получение $, повышение по карьере, соревнование, покупка новой железки. Это очень важный момент — как часто раздавая задачу подчиненному Вы думали о том, что его нужно мотивировать ее выполнять? Часто бывают «скучные» задания — грамотно проведенная и поддерживаемая мотивация творит чудеса. Это работает в любой сфере — от поля боя, до разработки ПО. Важно понимать, мотивация не формирует ФС, это даже не стадия ФС, но если нет мотивации — здравствуй выгорание у сотрудников.
Память
Если коротко то это "привычки". В контексте разработки это предыдущий опыт в системе управления разработкой программного обеспечения и отслеживания ошибок, git, паттерны решений, бизнес-правила как процедурная память. Это так же стандарты разработки кода и прочие наработки компании. Сюда же входит опыт разработчиков. Т.е. переводя на язык разработки каждая новая ФС будет опираться на накопленный опыт, так сказать привычки разработки. Есть множество книг "совершенного кода", но в них "выдирается" только эта небольшая часть из ФС, насколько они полезны конкретно в Вашей ситуации — большой вопрос.
Некоторые специально пытаются эту составляющую "упустить":
Скрытый текст
Чтобы интуитивно понять ее роль опять же небольшое отступление в медицину, точнее в фармакологию. Маркетинг фарм. препаратов подразумевает "обучение" врачей механизмам действия этих самых препаратов, а поскольку ФС неотделимы от физиологии человека (кому интересно погуглите Судаков К. В.), то их (ФС) иногда приходится фарм. компаниям рисовать, вот только память они не рисуют. А почему? - да все просто - привыкание к препаратам - это и есть биологическая память, это заложено в нас. Например, у нас есть ФС поддерживающая давление - это есть полезный результат, как только мы "едим" препараты понижающие его, "память" этой ФС меняется и резкая отмена или смена препаратов вызовет серьезные сбои в ФС.
В контексте работающей программы — это кэш как кратковременная память, сессия как контекстная память, база данных как долговременная память, собранные в дальнейшем ожидаемые результаты - память событий, ML-модели как обучаемая память, данные обстановочной афферентации.
Стадия афферентного синтеза
Небольшое отступление из медицинской терминологии, все что начинается с «афф» (афферентный) подразумевает сбор и поступление информации по рецепторам, а то что начинается с «эфф» (эфферентный) это характеризует какое то действие.
Для того чтобы сформировать ФС всегда нужен конечный полезный результат. Без КПР нет ФС — с него она формируется, им и завершается. Применительно к разработке ПО это напоминает SRS (Software Requirements Specification) — это структурированный документ, который детально описывает, что именно должна делать система, а не как она будет реализована технически.
Скрытый текст
Приведу шаблон для большого проекта (подробнее на вики стандарт ISO/IEC/IEEE 29148:2011):
Введение
• Цели документа
• Термины и определения
• Целевая аудитория
• Масштаб проекта
• Ссылки на источники
Общее описание
• Видение продукта
• Функциональность в общих чертах
• Классы пользователей
• Среда функционирования
• Ограничения и допущения
Функциональные требования
• Описание каждого функционального блока
• Алгоритмы и бизнес-процессы
• Приоритеты требований
• Координация действий с учётом состояния и компенсации при ошибках
Требования к интерфейсам
• Пользовательский интерфейс (UI/UX)
• API и программные интерфейсы
• Интеграции с внешними системами
• Аппаратные интерфейсы
Нефункциональные требования
• Производительность и масштабируемость
• Безопасность и надёжность
• Качество ПО и стандарты
• Требования к данным
• Требования к финансовым затратам
• Требования на интеллектуальную собственность
Приложения
• Глоссарий
• Диаграммы и модели
• Прототипы интерфейсов
Подмечу, что SRS не полностью соответствует конечному полезному результату - обязательно должны быть учтены следующие моменты:
обстановочная афферентация - это не разовое задание окружения в котором будет работать ФС, а постоянно меняющиеся требования. Этот момент прямо указан в ФС, поэтому правильнее будет добавить слово "меняющаяся" к SRS. Она постоянно синтезирует информацию о среде.
пусковая афферентация - это то, что запускает ФС (в том числе периодически). А вот времени окончания как раз нет. Это может показаться странным, как это при разработке ПО нет временных ограничений? ФС будет работать даже когда сроки разработки провалены, ФС завершается при достижении конечного полезного результата (а он может быть положительным и отрицательным).
Конечно же SRS не обязательно должна быть обширной и не обязателен никакой стандарт, но от правильности его составления зависит конечный успех. Требования будут постоянно уточнятся и "полироваться".
Скрытый текст
Приведу более короткий, и, кстати, не совсем корректный пример:
Тип: Функциональное требование
Описание: Система должна позволять пользователю восстанавливать
пароль через email.
Приоритет: Высокий, начало разработки с 1.01.2026
Требования:
Начало с мотивации пользователя восстановить пароль, он должен знать что такой функционал существует, легко увидеть где и как это можно сделать
Тригерром начала будет нажатие кнопки, сслыки, пункта меню, письмо в саппорт.
Пользователь вводит email на странице входа
Система отправляет ссылку для сброса пароля
Ссылка действительна 24 часа
После использования ссылка деактивируется
Должен быть предусмотрен механизм обработки ошибок совершенных пользователем.
Должны выполнятся требования глобальной системы разработки:
...
n. Сбор данных об эффективности работы системы
n+1. Ошибки возникающие при работе ФС должны доставляться их разработчику.
Почему этот пример не совсем корректный в контексте ФС - жду Ваших комментариев.
По времени разработки — составление SRS, или как мы уже выяснили формирования конечного полезного результата занимает продолжительный отрезок времени. По своему опыту скажу, до использования ИИ, доходило до 70% всего времени разработки, поскольку одного опыта тут недостаточно — нужен "ресерч", развертывание начальной среды разработки и т.п.
Важно так же сказать, что на стадии афферентного синтеза при выработке КПР можно и нужно привлекать, советоваться и выслушивать замечания компетентных в контексте людей, в том числе заказчика, инвестора и т.д. Но, важно, проводить все эти "совещания" по одиночке.
Стадия принятия решения
Вот прям выделяется то, что мы называем митапом, Scrum, Daily, Stand-up митингов - как не назови суть не меняется, но это не все. Что важно отметить здесь — митапы НЕ назначаются до тех пор, пока собирающий не нашел мотивацию (для себя в том числе), пока не проанализированы ранее сохраненные данные, пока не прошла стадия афферентного синтеза и не сформирован конечный полезный результат. При нарушении этого Вы будете слышать "мемы" про эти сами митапы (и не только в сети, а и в разговорах между подчиненными) и будет просто потеряно время. Всякий раз, когда Вы не имеете КПР перед митапом с командой, вы перекладываете (а не делегируете) свою работу. Делегирование — это индивидуально, перекладывание — это "на всех".
Не менее важная часть — донесение мотиваций (мотивировать на выполнение своих задач), КПР, возможно обновления предыдущего опыта (привычек разработки см. выше).
Итог работы стадии принятия решения:
Выделение ресурсов под эту ФС. Эта стадия в зависимости от выделенных ресурсов предусматривает масштабируемость, отказоустойчивость и параллельность работы системы. К примеру, по отказоустойчивости, в контексте: два DNS сервера норма, две ответственных за задачу команды разработки - тоже норма.
завершение работы если достигнут КПР. При достижении отрицательного КПР (например выход из бюджета) - отказ от реализации или дальнейшей работы.
Требования распределяются по ответственным, возможно добавление новых пунктов (как уже упоминалось ранее, в обстановочной афферентации, "меняющаяся" SRS это норма для ФС).
Скрытый текст
А сейчас, почувствуйте универсальность теории ФС, стадия принятия решения работает как при разработке кода, так и в уже разработанном и работающем коде. В этом кейсе - это код который теперь уже в рамках выделения ресурсов под ФС выбирает программу действий и соответствующие ей акцепторы результата действия (см. ниже), а так же останавливает ФС при достижении КПР.
Стадия афферентного синтеза тоже присутствует в работающем коде, если что. Эта стадия - одно из последних внедрений в ИИ — ризонинг-модели.
Стадия формирования акцепторов результата действия и эфферентной программы самого действия.
В контексте акцепторов результата действия (АРД) была "изобретена" разработка через тестирование (Test-Driven Development, TDD), опять ��е это лишь часть общей картины. Поскольку это так же метрики качества, A/B-тесты, сюда включается и QA отдел, аналитики ... Модель ожидаемого результата создается ДО выполнения действия - это "контракт" или "спецификация" того, что система ожидает получить. Кстати, вот те самые "ответственные" назначенные ранее в контексте разработки ПО частично и есть акцепторы результата действия.
Замечания:
Системы меняют поведение на основе нагрузки, метрик и бизнес-правил, т.е. параметры акцепторов результата действия меняются, но сам АРД стабилен - он в отличие от конечного полезного результата он не меняется и привязан к конкретной программе действия. Это означает, что он одновременно включает в себя и успех, и провал, и все другие исходы.
Устойчивость к неопределённости — то чего нет в КПР, на это нет акцепторов результата действия и этого не существует для ФС. Это означает, что на все, на что нельзя создать акцептор результата действия — выбрасываем. Вы удивитесь, сколько "ненужных" пунктов были лишними.
Каждый пункт КПР должен иметь акцептор результата действия — это означает что каждое требование должно иметь критерии проверки, быть однозначным, полным, непротиворечивым, верифицируемым, трассируемым (можно отследить с КПР). Т.е., например, даже термины и определения должны быть нужны и "донесены" до разработчиков и нужно контролировать их понимание и знание — не пишите "что попало" и "для галочки". Если вы в первый раз будете делать SRS, вручную, выпишите себе на листик вот эти критерии — поможет.
Любой пункт КПР может формировать новую ФС — чаще, начиная использовать ФС впервые, мы работаем с иерархией ФС. Новая ФС будет создаваться на основе пункта родительской ФС. Но не стоит углубляться в "бюрократию" - если нужно специально "выдумывать" пункты новой ФС ради ФС, значит Вы что-то делаете не то. Простые проекты, спокойно обходятся без ФС.
Скрытый текст
Деление на джуна, мидла и сеньора — ох, ох , ох... А что означает "простые задачи", "сложные задачи", "занимается архитектурой" — все расплывчато. Где задача становится сложной? Где начинается архитектура? "Незаменимый" программист COBOL — это сеньор? А если умеет создавать успешно работающие ФС — может это показатель.
Эфферентная программа самого действия — это самая проработанная на сегодня в контексте разработки ПО часть ФС. Наиболее подходящее определение — это паттерны разработки. Это конкретный алгоритм/код, который выполняется для достижения результата, предсказанного АРД. АРД — это «что», эфферентная программа — это «как».
Эфферентная программа может меняться, АРД стабилен. Программа не всегда выполняется до конца линейно, она должна предусматривать точки проверки - простыми словами - она может меняться, но если программа не содержит критериев валидации, система становится «слепой».
Отсутствие жесткой детерминированности — это требование ФС. Для конечного программиста это означает с одной стороны "проверяем" все переданные параметры, экранируем все, модель try-except, с другой — адаптацию к изменяющимся условиям, в зависимости от обстановочной афферентации. Например, ожидаем, если процессор загружен на 90%. Для простоты можно рассмотреть это как набор программ выполняемых в зависимости от текущих параметров.
Программ действий может быть множество, но при этом будет запускаться будет только несколько, а на стадии принятия решения выбираются какие. Чего не может быть — это программы действия без АРД.
Получение результатов действия и формирование обратной афферентации
Наиболее простым термином для этой стадии будет запись в память (конечно же имеется ввиду память ФС) и обучение системы. Это отдельная "суммирующая", но не завершающая стадия в ФС. Частой ошибкой бывает смешивание ее с предыдущей стадией - эта задача не входит в программу самого действия. Она включает в себя:
Получение параметров результата — извлечение фактических характеристик выполненного действия
Сличение с АРД — сопоставление фактического результата с запрограммированным (ожидаемым)
Оценка рассогласования — определение наличия и величины ошибки. После оценки управление передается на стадию принятия решения.
Скрытый текст
Сравнение параметр за параметром:
✓ Status: 201 ∈ {200, 201}
✓ ID: "123..." matches UUID pattern
✓ Email: valid format
✓ Time: 234ms < 500ms
✓ Side effects: all present
Рассогласованние: 0% (полное совпадение)
На этой стадии происходит формирование обратной афферентации и доставка по каналам обратной связи. Эта связь обязана присутствовать в ФС. Исторически на веб страничках конечного продукта компании начали возникать форумы поддержки, появились комментарии и логи в программах, появилось слово телеметрия — примеров фидбэка множество. Устойчивая IT-система или бизнес процесс обязательно должна иметь контур обратной связи — без него невозможно адаптироваться к изменениям.
Важно — контур обратной связи должен замыкаться на том, кого назначили на стадии принятия решения, кто может принять решение по оценке, исправлении или доработке. Например если в функции А возникла ошибка, то фидбэком информироваться должен разработчик (ответственный за создание) функции А. Часто этот момент ошибочно подымают "выше" замыкая, например, на тимлиде, или еще выше.
Ключевые принципы:
• Обратная афферентация должна быть полной — собирать все параметры, не только успешные
• Сличение должно быть детализированным — не просто "совпало/не совпало", а по каждому параметру
• Обработка рассогласований должна быть адаптивной — разные стратегии на стадии принятия решений для разных типов ошибок рассогласования. Например:
Скрытый текст
• При критических рассогласованиях:
◦ Откат изменений (rollback)
◦ Логирование
◦ Уведомление
◦ Возврат ошибки
◦ Компенсация в обратном порядке
• При временных рассогласованиях:
◦ Экспоненциальная задержка
◦ Повторное выполнение
• При допустимых рассогласованиях:
◦ Пр��менение дефолтных значений
◦ Логирование предупреждения
• АРД должен быть стабильным — меняться только при изменении бизнес-требований
• Цикл должен быть быстрым — минимизировать задержку между действием и обратной афферентацией
Итоги
ФС работает для любого масштаба — даже в отдельно взятой функции, скажем на Си, может быть заложена ФС целиком. Вы программируете простую функцию и даже не замечаете, как сами создаете в ней полноценную ФС.
ФС работает на всех уровнях — ответственным за ФС может быть тимлид, тех. директор, разработчик, и даже уборщик.
ФС содержит саморегуляцию — способность автоматически обнаруживать и корректировать отклонения от цели, обеспечивая адаптивность, масштабируемость и управляемость любого процесса.
ФС предусматривает обучение системы, поскольку постоянно меняющиеся требования лежат в ее основе.
Основная цель ФС — достижение конечного полезного результата. Важно, если нет цели — нет ФС.
Гомеостаз — независимость внутренней среды от внешней. Простыми словами: Чем хуже внешняя среда, тем труднее поддерживать внутреннюю. Вы должны стремится поддерживать гомеостаз на любом этапе разработки — и это позволяет сделать ФС. Если нет возможности поддерживать независимость внутренней среды — для живого организма это равносильно смерти, для проекта — аналогично.
ФС в разработке ПО — это своего рода «франшиза» по разработке. Создав одну для решения какой то задачи, Вы сможете постоянно ее переиспользовать. Не бойтесь ошибаться, главное не лениться — ФС просто дольше будет достигать своего КПР.
Но с приходом ИИ все меняется, все больше и больше ИИ берет от компонентов от ФС. SRS еще 2025 году нужно было «руками» делать, а сейчас, в 2026, c этого начинается разработка. При текущих темпах развития ИИ может отобрать разработку кода и отберет если это будет полноценная ФС.
