(как я например использовал для демонстрационной игры Змейка -- самые сильные на сегодня в математическом смысле),
толку от них будет абсолютный ноль и вся система мгновенно развалится, достаточно дать совсем немного слабины на уровне programming in large.
Форматирую для курса код Змейки, который нагенерил
"...в полностью агентных задачах лидируют SWE-Agent, Github Copilot (VSCode), Windsurf - почти все на базе нашей любимой Claude 3.7 Sonnet."
и вроде бы он всё сделал чётко по моим инструкциям, где я требовал строгого соблюдения функционального стиля, и работает игра нормально, и кода фактически немного, и сама игровая логика на уровне буквально начинающих с нуля, и тут....
Глаз зацепляется вот за такое:
def toggle_pause(self, state: GameState, engine) -> GameState:
engine.toggle_pause()
return state
WTF??
То есть для галочки AI сделал функцию в чисто функциональном стиле, да вот только логика её оказалось кривейшей глобальной зависимостью.
Ну и следом потянулись фиксы на всю игру, и на все семь файликов, и фактически всё пришлось переписывать заново... на возню в итоге ушло несколько часов, потом полезли баги, я руками сделал бы реально быстрее.
А всё потому, что я не следовал своему собственному курсу по вайб-проектированию (он кстати не столько про вайб, сколько про проектирование). Тогда подобная хрень с зависимостями была бы полностью исключена на фазе скаффолдинга, когда мы формируем интерфейсы и частично реализованные функции и абстрактные типы данных, отодвигая реализацию как можно дальше.
Но зато на удивление естественно и продуктивно в вайб-проектирование укладывается мой трек по ООАП: я сейчас рекомендую всем, кто прошёл с него третий курс (делаем проект по предлагаемой методике), перепройти его заново уже в связке с AI и с учётом новых рекомендаций.
=
А главный вывод в том, что, как закончу второй курс по базовой теории HoTT, надо будет думать прежде всего в направлении топологически-ориентированного проектирования: как всю эту могучую силушку гомотопической теории типов залифтить до programming in large.
Некоторые подходы достаточно очевидны: активно задействуем эквивалентности и унивалентности для безопасной сборки из независимых компонентов (+ динамическое обновление модулей без нарушения инвариантов). Можно заменить DI-контейнеры автоматической генерацией адаптеров между интерфейсами и реализациями. Можно определить классические паттерны (фабрики, стратегии) через высшие индуктивные типы, чтобы тайп-чекер автоматически проверял их корректную композицию.
Но это всё остаётся всё же какое-то половинчатое programming in large in small. Можно например попробовать кодировать бизнес-правила и ограничения как "пути" между зависимыми типами...
Пока не знаю, размышления продолжаю.
Существуют парадигмы, и парадигмы на ранних этапах разработки программного обеспечения очень помогли нам. Например, структурное программирование намного лучше, чем goto, это здорово, это действительно сэкономило нам много времени...
но большая часть работы, которой все занимаются целый день, не имеет ничего общего с парадигмами программирования, и точка.
-- Фредерик Брукс